You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
(23) |
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(3) |
Feb
(4) |
Mar
(29) |
Apr
(13) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
2004 |
Jan
(2) |
Feb
|
Mar
(10) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2007 |
Jan
(3) |
Feb
|
Mar
|
Apr
(7) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
(6) |
Nov
(4) |
Dec
(3) |
2008 |
Jan
(5) |
Feb
(17) |
Mar
(27) |
Apr
(16) |
May
(16) |
Jun
(8) |
Jul
(18) |
Aug
(14) |
Sep
(5) |
Oct
(11) |
Nov
(27) |
Dec
(26) |
2009 |
Jan
(25) |
Feb
(6) |
Mar
(14) |
Apr
(32) |
May
(84) |
Jun
(78) |
Jul
(31) |
Aug
(16) |
Sep
(21) |
Oct
(39) |
Nov
(7) |
Dec
(7) |
2010 |
Jan
|
Feb
|
Mar
(36) |
Apr
(58) |
May
(77) |
Jun
(56) |
Jul
(42) |
Aug
(45) |
Sep
(22) |
Oct
(7) |
Nov
(2) |
Dec
|
2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Nick R. <ni...@fa...> - 2003-03-09 18:14:28
|
On Sun, Mar 09, 2003 at 05:26:34PM +0100, Jelle wrote: > Quoting Nick Rusnov (ni...@fa...): > > Personally, I would strongly prefer moving to a meta-level when > > approaching projects. While having sheets have resources and making [...] > OK Imagine the following, somewhat along the lines of AfterEffects and > MSVC (and Anjuta to some extent). > The project is a tree (displayed on the left side) that consist of > all times in the projects. > > For galan this tree (project) would consist of [...] > We would then have a (nr of) "master" projects that lists defaults: [...] > the project does all the disc handling and the generators etc that use > the resources just get a reference (ptr*) to an instance of resource. This is excellent. I hadn't really thought of the UI for the project idea but this is pretty good. It could even be one tree. Just details. Might be easier to have everything grouped into one list though. > It becomes important to generalize sheets and generators so that the two > different presets can be unified. Ah excatly. I was going to mention this above, but you already thought of it. > you also don't have the problem of "magically availiable" sheets no > more. If the sheet "jelle" is in the std library doesn't mean it's > automagically available for every project. It needs to be added to the > project first. Hmm. Perhaps the tree should only show things in the actual project then, and when you add it provides a complete list to choose from based on your search paths for modules and sheet libraries (of which the default system and project lib dirs would be included). > Additionally we could provide a function thata gathers all the > files/resources to one folder or maybe even to one file. aftereffects > works like this. Yes. > > > Maybe there could be some kind of Component install system (like a text [...] > I think David meant actually getting binarys from some public > repository? but this would not be possible because of diff. > architectures, so maybe not... The way I'd suggest approaching this would be to make it possible to compile new generators using galan-dev-alike package or whatever that'd provide headers and any libraries needed to build them; then providing this package with the binary distributions, have it created at build time also for people who compile and install. Then generator and other modules that are 'external' to the galan distribution could be packaged and distributed easily through the normal channels. [...] > This seems a bit silly, because some gui items like ADSR are actually > just 4 * control inputs. If you make it a gui port you cannot control > them and if you make it a i/o port you cannot "gui" them. Its very silly. My vague thoughts about this are in regards to the fact that almost all generators currently have the ability to take input for their controls in the form of events rather than using their internal controls. Given this, the skinned gui should be like some sort of octopus that surrounds the component (internally to the sheet), and provides N event (output) nodes and M event (input) nodes, and draws a nice graphical control panel based on a 'skin profile' thats been loaded into it. Then one or more of these exist in a sheet, generally grouped logically such that they fit together into a nice skinned control panel. Whew. -- -><- Nick Rusnov -><- http://nick.industrialmeats.com -><- ni...@fa.../nic...@de... |
From: Nick R. <ni...@fa...> - 2003-03-09 18:09:24
|
On Sun, Mar 09, 2003 at 06:19:32PM +0100, Jelle wrote: > yeah, this is real bad. I personally have not problems with using > libraries like gktmm, sdl, glut etc (on Debian unstable that is). > The OSG lib I mentioned does give me problems because it's not in debian > (yet). I need to get the latest version from CVS and recompile every now > and then when gcc is updated, this is annoying, but I suppose that's the > price you pay for cutting edge stuff. There is supposedly an ITP (intent-to-package) OSG, but it seems dead in the water, maybe some mail to the potential future maintainer will speed it up or something; see: http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=172189 > About that abstract rendering protocol; > I think we need to provide two kinds of operations, 2d-pixel based stuff > and 3d stuff. Yes. > We use SDL to display the 2d stuff, and just self written (or some lib > maybe) algorithms to manipulate the 2d stuff. > textures for example. This is exactly what I was proposing. > OpenGL can do quite some 2d stuff but that's okey, the SDL support is > only for when you do not want to use openGL (on machines without a gfx > accelerator for example) or when you want to do stuff on 2d data that > openGL cannot do. OpenGL visualizer should be able to impliment most of the 2d protocol, so it could be used universally if you didn't want to diddle with SDL. SDL should be the reference implimntation of the 2d protocol. > Instead of using opengl directly we can use OSG, this saves us a LOT of > work. Using a scenegraph sounds like a good idea. Wow, nice to see discussion on the list. :) -- -><- Nick Rusnov -><- http://nick.industrialmeats.com -><- ni...@fa.../nic...@de... |
From: Nick R. <ni...@fa...> - 2003-03-09 17:54:01
|
On Sun, Mar 09, 2003 at 03:32:43PM +0100, Jelle wrote: > > > > My sheet library is growing i can make that available on the web-page. > > > > > > That'd be nice. It'd be nice to have an official sheet library as part > > > of the distribution in /usr/share/galan that is in the menu as > > > components that cant be added. > > > > s/cant/can/ > > > > what should be in there ? > > > > i currently have > > - drumbank > > - master sequencer > > - simple voice > > - filter + delay > > - sync osc (for nice basslines) > > Maybe someone (me?) can have a look at what's in reaktor for example? Nabbing well-designed sheets from other programs, or at least the ideas of them, is an excellent idea. Perhaps we should come up with some sort of .. interface standard that /usr/lib/galan sheets should comply with so that the user knows what to expect from all the 'galan provided sheets'. -- -><- Nick Rusnov -><- http://nick.industrialmeats.com -><- ni...@fa.../nic...@de... |
From: Jelle <wi...@xs...> - 2003-03-09 17:20:42
|
Quoting torben hohn (to...@gm...): > > > nice to hear from you again... > > > > yeah, I was totally drenched with schoolwork, and still am... > > > > i've been working on gtkmm components in case we want to port galan > > to C++ or python, i've started on a sequencer "widget" and a sheet > > cybolic is working on a matrix widget in python... > i also tried to build a python capsule using pyrex... > but i did not succeed yet :( > > concerning C++ i am beginning to like it somewhat again... > > But i will only begin to use C++ libraries, if there is a standard > for name mangling, and if you can link stuff built with gcc 3.x > with stuff gcc 3.y built.... > > i dont want to be distributing n libraries only because galan links > to them, like ardour does... yeah, this is real bad. I personally have not problems with using libraries like gktmm, sdl, glut etc (on Debian unstable that is). The OSG lib I mentioned does give me problems because it's not in debian (yet). I need to get the latest version from CVS and recompile every now and then when gcc is updated, this is annoying, but I suppose that's the price you pay for cutting edge stuff. > > "widget". But i'm low one spare time, i'll (ofcourse) mail you the > > results when there is anything interesting. I'm also investigating > > openscenegraph, this seems to be excellent to use as a base for > > graphics-enabled galan. > > what does that do ? > nick suggested we should build an abstract rendering protocol > which can be translated to opengl,sdl, whatnot... OSG does something like this this. You have nodes like a osgText, osgPrimitive, osgTransform, etc. By creating a graph, you build up a scene, much like how opengl is handled in galan right now. Say I build up a cube from osgPrimitives and then I would like to manipulate that cube, rotate it for example. All you need to do it add a osgTransform node as a parent to this cube node (group). You then alter the transform node properties. All we need to do is provide a way to convert the node properties into control ports and the nodes into generators. Have a look at the screenshot of http://osgedit.sf.net/, this should give you some idea. But it's all C++ ofcourse. About that abstract rendering protocol; I think we need to provide two kinds of operations, 2d-pixel based stuff and 3d stuff. We use SDL to display the 2d stuff, and just self written (or some lib maybe) algorithms to manipulate the 2d stuff. You can also use opengl possibly mixed with the 2d stuff to generate textures for example. OpenGL can do quite some 2d stuff but that's okey, the SDL support is only for when you do not want to use openGL (on machines without a gfx accelerator for example) or when you want to do stuff on 2d data that openGL cannot do. Instead of using opengl directly we can use OSG, this saves us a LOT of work. There was also some stuff on using this abstract protocol for rendering the GUIs but I think this is not the way to go. Visual representation should be all up to the GUI and out of the plugins IMHO. Take VST for example, i'm not so keen with that all plugins look different etc, i'd rather have some abstract (but well defined) interface to their parameters and render those myself (so all plugins look consistent). > > i've also tried the new .3 galan, but I cannot get jack support to work > > (not galans problem, my problem :)). I've got a ("new") sek'd prodif > > But without jack it was usable ? Yes, or atleast I think it worked as usual? > if i fix the memory handling in the event system i will add a config > value which should make the audio thread SCHED_FIFO... > then you would benefit from the 0.3.x branch even if you only got > OSS... I got ALSA, but not jack. bye, Jelle. -- http://defekt.nl/ |
From: Jelle <wi...@xs...> - 2003-03-09 16:26:39
|
Quoting Nick Rusnov (ni...@fa...): > > If I understand what you guys are talking about, the entire project would > > have it's own resources (lib, graphics, etc) What if it was still sheet > > based, but each sheet could have it's own resources. This way (if you look > [...] > > This is all perfectly reasonable. > > Personally, I would strongly prefer moving to a meta-level when > approaching projects. While having sheets have resources and making > things sheet-centric is interesting and even good, I think there needs > to be a way of saying 'all these things belong to a project, they all > fit together this way, these are all the files needed'. Its just such > a useful concept. OK Imagine the following, somewhat along the lines of AfterEffects and MSVC (and Anjuta to some extent). The project is a tree (displayed on the left side) that consist of all times in the projects. For galan this tree (project) would consist of -sheets -additional presets (knob settings) for sheets for this proj. -generators -additional presets for this project -samples/video/images/models/other resources -additional settings such as resource dirs, etc We would then have a (nr of) "master" projects that lists defaults: -reusable sheets library -their presets -all available generators -their presets -samples/video/images (directory listing) so now we display two project trees, one on the topleft, the "master" project and the current fresh project on the bottomleft. By dragging a generator from the master to the project sheet you add this to the sheet (clone), same with samples/etc, sheets, presets, etc. The other way around adds a item to the master project, or to your "standard library". the project does all the disc handling and the generators etc that use the resources just get a reference (ptr*) to an instance of resource. It becomes important to generalize sheets and generators so that the two different presets can be unified. you also don't have the problem of "magically availiable" sheets no more. If the sheet "jelle" is in the std library doesn't mean it's automagically available for every project. It needs to be added to the project first. Additionally we could provide a function that gathers all the files/resources to one folder or maybe even to one file. aftereffects works like this. > > Maybe there could be some kind of Component install system (like a text > [...] > > that look interesting, and installing them. > > This would be handled through either sheet library search paths or by > explicitly loading modules, I think. I think David meant actually getting binarys from some public repository? but this would not be possible because of diff. architectures, so maybe not... > > What about a seperate system for panel design? [...] > > if you are interested in building a panel you can run a seperate > > system (or another system entirely like glade or something...) to > > make panels. > [...] > The way I see it, the skinned panels would exist in the same place as > the non-skinned panels. [...] > Of course at any time you could drop into the standard > network editor, and see the same patch panel in the network editor and > be able to add parts at will and edit the other sheets at will. For this to be really usefull I think we need to completely seperate the GUI stuff from the plugins and provide an abstract basis for each "widget". There will be the galan core which is just a graph of dsp nodes and there will be the galan GUI which is visualizes the graph and allows modifing the parameters. This do not have to be seperate processes, but it would be nice if they could be (adds some overhead). That way we could create a reason interface to the galan core and at the same time edit it with the graph (sheet) interface. All the custom GUI widgets need to be standarized. We need to provide an API for them. If we need a new gui widget, eg a adsr display we need to create a ADSR api and add it to the galan base. then someone who wants a reason interface can implement a reason-look-alike-ADSR-manipulator. You know how Reaktor looks (for example)? There is a window on the right side of the screen (you can move it) that displays the properties of the selected generator (node). Ultimately we want something like this in galan to. Something like a "default panel". It could display faders with a range for all the i/o ports. Or buttons if that is more appropriate. The "custom" widgets can then also be displayed because we know how to manipulate them. If we implement this nice we could have two GUIs manipulation one core at the same time or multiple cores manipulated by one GUI. Hurray! Anyway, this is just conceptual because actually implementing this is a whole different (difficult) cake. AFAIK there is no software that allows complete seperation of DSP-core and GUI (apart from the nord modular). Some more thoughts: each generator then has - event i/o ports - control i/o ports - gui ports - ra ports This seems a bit silly, because some gui items like ADSR are actually just 4 * control inputs. If you make it a gui port you cannot control them and if you make it a i/o port you cannot "gui" them. The nord modular handles this by not making the actual ADSR values inputs, but by creating a display with 4 knobs that set the ADSR values and then provide 4 inputs to the module that modulate values set by the knobs. The amount of modulation can be modified by another 4 knobs. This works very well, and regular 100% control is still possible by just setting the amount of modulation to 100% and the initial values to 0. Because it is possible to manipulate the ADSR values at audio rate 96khz the display is no updated to represent the actual values after manipulation by the inputs. For an ADSR envelope an approach like this would work, but maybe not for all custom panel controls? Any thoughts on this? Jelle. -- http://defekt.nl/ |
From: Jelle <wi...@xs...> - 2003-03-09 14:32:48
|
Quoting torben hohn (to...@gm...): > > To be really useful the ability to save control settings as part of > > the project, not as part of the sheet would be good, too. So all the > > sheets remain pristine in the 'library', and the project keeps track > > of the changes to the settings in them. > > yes. That would be very good. But this would require much code > changes. At the moment there is Events/Settings this can be used > nicely for saving settings in the synth. As a side note, I'm using the nord modular synthesizer a lot, and one of the big complaints against the current OS is that just this. You build a synth (sheet) and the create a number of presets for it that basically just alter knobs and buttons. You cannot save these presets in the sheet, but you need to save the whole sheet for each preset. This makes switching between and saving presets clumsy. Another advantage of presets could be `morphing' between presets, as in crossfade all settings from a to b. > > > My sheet library is growing i can make that available on the web-page. > > > > That'd be nice. It'd be nice to have an official sheet library as part > > of the distribution in /usr/share/galan that is in the menu as > > components that cant be added. > > s/cant/can/ > > what should be in there ? > > i currently have > - drumbank > - master sequencer > - simple voice > - filter + delay > - sync osc (for nice basslines) Maybe someone (me?) can have a look at what's in reaktor for example? Jelle -- http://defekt.nl/ |
From: Nick R. <ni...@fa...> - 2003-03-08 02:02:24
|
On Fri, Mar 07, 2003 at 04:55:19PM -0800, David Konsumer wrote: > I'm not sure I understand all the concepts that are being discussed, but I > have a few ideas that I think go with this. You'll get the hang of it. ;) > If I understand what you guys are talking about, the entire project would > have it's own resources (lib, graphics, etc) What if it was still sheet > based, but each sheet could have it's own resources. This way (if you look [...] This is all perfectly reasonable. Personally, I would strongly prefer moving to a meta-level when approaching projects. While having sheets have resources and making things sheet-centric is interesting and even good, I think there needs to be a way of saying 'all these things belong to a project, they all fit together this way, these are all the files needed'. Its just such a useful concept. > Maybe there could be some kind of Component install system (like a text [...] > that look interesting, and installing them. This would be handled through either sheet library search paths or by explicitly loading modules, I think. > For the user/developer that is looking to do more with it, it's still just [...] > necessary as a good wave editor. ... > What about a seperate system for panel design? This way most people can > just use a better-then-Reason Linux Reason, but if you are interested in > building a panel you can run a seperate system (or another system entirely > like glade or something...) to make panels. This way there can be more We have the 'glade or something' right now. :) > casual users, who don't care about learning the concepts of building synths > (My roomate likes using a panel I created, but is totally uninterested in > building his own, for example.) Maybe even have the control panel come up > as default interface (with a defualt project loaded), and show the guts > screen, off of a menu. this separate mode of use idea has been broached: I personally thing its a good idea, and I think in my description of skinned panels I went into this a little. The way I see it, the skinned panels would exist in the same place as the non-skinned panels. The only thing we really need is some sort of 'skinned patch panel'. I think this would be accomplished by a separate wiring editor module that would present each module through its 'skinned' connection list, the idea being that the modules available through this system would be high level objects or whole sheets that would have very simple, or even standardized interfaces, like stereo and rack components. In this mode of use you wouldn't start in the ntework editor window, you'd start with a control panel window and an empty patch-bay window, and it'd give you a menu of high-level sheets and parts that comply with the skinned component standard. Of course at any time you could drop into the standard network editor, and see the same patch panel in the network editor and be able to add parts at will and edit the other sheets at will. > When I'm in Windows, I use Fruitty Loops over Reason. It has alot more > control, more filters and modules, and I think it's generally easier for me > to work with, so I guess I'm also thinking in those directions. Reason's > interface is pretty snazzy, though. Fruityloops is nice but not as similar to gAlan as Reason is. gAlan is like Reason on Steroids, as far as I can tell. I picked reason because its a good thing to go for on the skinned side of things. THe actual network editing is much more flexible than the patch-panel thing that reason has. -- -><- Nick Rusnov -><- http://nick.industrialmeats.com -><- ni...@fa.../nic...@de... |
From: David K. <kon...@to...> - 2003-03-08 01:22:17
|
I'm not sure I understand all the concepts that are being discussed, but I have a few ideas that I think go with this. If I understand what you guys are talking about, the entire project would have it's own resources (lib, graphics, etc) What if it was still sheet based, but each sheet could have it's own resources. This way (if you look at that Reason screenshot again) Each component module (sampler, drum machine, 303, midi plugger, etc) could have it's own individual resources, and you could mix and match audio equipment components. I use the new sheet system this way, anyway, making a "main" panel, then building each sheet as a component, and adding a control for them so they are all on one screen. I save each sheet, and it's interchangeable in other panels. I think also knob-positions should be stored seperately from the actual components (maybe allow defaults, though) because I always have to zero out all the knobs, and remove all the notes/triggers before I save each sheet (modular component) so I can reuse it easier. The project file could then handle things like storing performances (I really like the terminatorX method, every knob/button/etc movememnt is stored in a linear, realtime timeline), the theme, and other stuff that wasn't specific to a single component. I like the idea of having everything self-contained in a tgz file. It sucks when you forget to back up your samples. It might be cool to give the option of loading external samples (like the Sampled Voice object already does) Maybe there could be some kind of Component install system (like a text file) that keeps the name of all the equipment components, the files needed for each (special plugin libs, python files, special graphics, etc) This way you could just install a component, then use a menu option to show or hide different components. This way it would be easier to extend then Reason, but for the casual user, it would be as easy as downloading the components that look interesting, and installing them. For the user/developer that is looking to do more with it, it's still just as easy, and can be extended with python, skinned, reworked with custom C plugins (on a per modular components basis) whatever. Standard setups could be arranged to make it even easier for gAlan newbies to make cool songs. I bet if you could make it easier to do more advanced stuff, and make it look cool, it would be WAY more popular. I don't think I know a single casual windows user, that is interested in making music, that doesn't have some sort of sequencer/synth progam (reason/rebirth/fruitty loops/etc) . It's as necessary as a good wave editor. What about a seperate system for panel design? This way most people can just use a better-then-Reason Linux Reason, but if you are interested in building a panel you can run a seperate system (or another system entirely like glade or something...) to make panels. This way there can be more casual users, who don't care about learning the concepts of building synths (My roomate likes using a panel I created, but is totally uninterested in building his own, for example.) Maybe even have the control panel come up as default interface (with a defualt project loaded), and show the guts screen, off of a menu. Maybe I'm getting carried away here. I suppose I'm talking about reworking alot of different things, but these are just some ideas I had. When I'm in Windows, I use Fruitty Loops over Reason. It has alot more control, more filters and modules, and I think it's generally easier for me to work with, so I guess I'm also thinking in those directions. Reason's interface is pretty snazzy, though. -David |
From: <to...@gm...> - 2003-03-07 08:29:01
|
hi... I will go to the lad conference next weekend. and i would like to have galan-0.2.14 ready then. currently implemented in cvs is - liblrdf support which orders LADSPA plugins in a better menu-hierarchy. - the discreet thing from david.. - some bugfixes: the pops from the filter will go away. i will try to think of more features. But i will begin to move to a new house next week, so i wont have too much time. an update to the sheet library is now necessarry. so this is a call for you to send me your sheets. i would also like to extend the ogg section in the galan-www i have made 2 tracks of mine available on the website... so if you like to criticise my musical skills, you are welcome :) -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language |
From: Nick R. <ni...@fa...> - 2003-02-28 16:58:31
|
On Fri, Feb 28, 2003 at 05:31:08AM +0100, to...@gm... wrote: > shit not mailed to list... Heheh. > On Thu, Feb 27, 2003 at 09:09:04AM -0800, Nick Rusnov wrote: > how do we associate the state file with the sheet > data we have to load before the state can be filled in ? See, this is what I mean by moving away from using a sheet as the central saving mechanism. SURE we should pickle the sheets as part of a project, but a project is MORE THAN JUST PICKLED SHEETS. It needs a separate file to contain the state including resource paths, patterns, and everything else that needs to be basically loaded once the sheets are all initialized and setup. > yes nice. but wait... > how about an strcat component ? > > sample.wav > / > /the/path/ / > \ / > \ / > strcat > | > | > /the/path/sample.wav > > This would provide something like paths on the galan level... > we could then provide a component emitting /the/path on every > load... multiple paths would be an array of strings, which > strcat would convert into an array of cat strings... > > sample component should try to load all strings in array... > > this is very easy to implement. > But somewhat contrary to your proposal... > ok back to the abstract object handle... > > the object handle component holds a reference on the > resource... so pickeling it would save that to disk... This is an interesting approach, but you're right, it is contrary to my proposal. I'm thinking something like how libraries work from the compiler's point of view .. in fact nearly identical. Think of the resource paths as the library search paths, and the resources like arguments. The little translator component would search each path to satisfy the resource request and then provide a filename output. In fact, this'd be a better way to manage it. Have a global 'path list' in galan itself. Have a resource lookup component. Have a 'preferences' and file selector button and string input, all of which allow you to find a file or simply name a file. If you choose to find a file, the path that the file is in will be added to your resource search list, the file will be added to the list of resources you use and the resolved filename will be outputted. If you just name a resource, say 'hihat.wav', it'll search all the paths in your list and then prompt you to find it. Adding the resource to some sort of 'used resource list' associated with the *project* allows the project in its totality to be assembled for export. This would simplify the project export task: simply copy all the needed resources and sheets to a directory that the user can tar up and send to his freind. > > * Bitmap or skinnable control panels were mentioned in passing. Torben ... > how are these interfaces set up ? > the track me and david are now following tries to enable the user to > build these skinned control panels like any other panel. I'm thinking that there is a layer between the actual GTK widgets and the components that use them. So the control model is abstract, and you could 'intercept it' on a sheet level. So instead of a component drawng a knob or something, it can interact with a knob on a skinned control panel. I was under the impression that this was the way winds were blowing with the idea of alternate control panels. Alternatively, another option would be a whole other shell. Because the things like Reason also have skinned patch panels that are like connecting audio components together. This is similar to the idea of locking the user into just connectiong sheets together for newbies, except prettier. Not terribly important though :) > the python track i began yesterday gives us more flexibility though. > a skinned interface could be coded in python then... > (and python code can be part of the project) I was thinking about how this could work, and I could see it, if the python object could draw to the control panel area at will. I'd rather have a formalized skinned interface plugin or mechanism though. > opengl and sdl on the output ? do i understand this right ? OpenGL OR SDL. You say that OpenGL and SDL have similar capabilities for 2d. Then you say, okay, so we can distill these 2d operiations into a formal graphing protocol that can be 'adapted' by a component to the actual canvas: ----> graph_to_opengl --> opengl_canvas / vu-meter--/-----> graph_to_sdl --> sdl_canvas Of course the opengl canvas would speak whatever it speaks now. The sdl canvas may speak something similar. The beauty of this is that you could make an adapter for, say, DRI, so you have a DRI canvas that takes up a whole Xinerama screen. Or you could make an adapter for some kind of web thing so somebody could watch it. Or an adapter for an LED matrix driver attached to the serial port. Whatever. :) > ok.. what can the graphing protocol do ? > > - paint bitmap at (x,y) > > - render this vektor interpolated onto box (x,y,w,h) > > - have a component scale/translate a (x,y,w,h) tuple... > > - hmm.. more does not come to my mind > (this is already quite powerful... but having only 3 capabilities > makes me think this protocol is too general) Yea, I'm not sure how the protocol should work. I think maybe there should be low-level (draw a line) AND high-level (draw a histogram) stuff, and that the canvas adapters would know what to do for any given canvas. Eeither that or the protocol would be completely low-level and we could expand it later. > > > > Incidently, I feel that an abstract graph protocol for drawing > > visualization would aid in the advanced skinned control panels too. > > having thought about it i begin to believe what you feel :) Do you see what I mean? What I meant was that with an abstract graph protocol and some sort of skinned control panel infrastructure, panels that look JUST LIKE real components could be made. So the VU meter would output, instead of directly to a canvas, to a canvas embedded in the control panel at the right spot. This is similar to Reason, again. I think overall, reason is a good goal to look at. It is not exactly the same, but similar enough that it could be *implimented in galan*. Galan is powerful enough that weu could impliment that and still have the flexibility to crack open the guts of the rack component and change it around. Reason can't do that as far as I know. > the sampler cant really display a "now playing" cursor... > oh it can... the rart continously asks it for samples... > these function must save the positions... nice... Yea. The loop sample players duplicate some of the functionality of samplers and sample inputs, but I think they are cool enough that I'm willing to ignore that. :) They aren't as discrete as other components, but i want em anyway. Incidently, I'm thinking that they act like RA->RT converters. They would take input from a RA source like a sample input, and then fill their buffer with it, and have an internal clock maybe and show playing position, looping through the sample and also allowing you to move the play cursor interactively. I guess they could have an extrenal clock instead. Of course they output a RT signal just like a RA-RT converter. I'm not sure. But this is the overall operation I'd like to see. So in summary, like an interactive RA->RT converter. :) THey could have event connectors for start, stop, seek, and output start, stop, seek, position and loop. So they could be used programmaticly OR interactively. Very powerful. This is why I like galan. :) -- -><- Nick Rusnov -><- http://nick.industrialmeats.com -><- ni...@fa.../nic...@de... |
From: <to...@gm...> - 2003-02-28 07:58:24
|
shit not mailed to list... On Thu, Feb 27, 2003 at 09:09:04AM -0800, Nick Rusnov wrote: > On Thu, Feb 27, 2003 at 07:48:14AM +0100, to...@gm... wrote: > > nick, can you post some ideas and issues from our irc > > sessions ? > > Lets see if I can dredge up the memories :) :) ok.. this mail is not complete but i will send now... more to come... > > * My major desire is a sort of coherence in the save file system. > > Right now its totally sheet-based. This is fine for what we have, > but to be really great I believe it needs to be project-based. What > I mean by this is that the idea of a project needs to be inserted > into galan. A project is composed of: > > * 1 or more sheets > * 1 or more library paths (including the system sheet library path) > * 1 or more resource lists (images, models, samples) yeah... resource paths. great. > * A tar file or path of resources > * All the transient data associated with the controls such as > patterns, settings on dials, etc. > > A project would need to be able to be exported as a 'project > archive' that would be able to be distributed (so you could ensure > that an entire project is transported when you distribute it, with > all the required, samples and patterns and everything). > > The default project would be: > > * A blank sheet 'main' > * The system library path > * The system resource path > > Anyway. This is a major feature, probably some doing to impliment, > but it could easily built in stages, as I see them: > > * THe ability to save transient data, either associated with all > the sheets loaded or a particular sheet, to a file. I would > think the ideal way to do this would be to add a savedata method > to all the sheet objects that would serialize their internal > storage to a stream or buffer. This is well along the lines of > separating the assembly and arrangement of things from the data > of things. Spirit and body. Sweet duality. i believe this is rather easy to implement... i have already written some code on that path... this is like a special gen_pickle method which only calls the pickle of the generator subclass but does not pickle the links of the generator... how do we associate the state file with the sheet data we have to load before the state can be filled in ? > > * The ability to associate resources with abstract handles. This > would work with a resource manager that would, for example, > allow you to select a file, give the file an ID, and then a > component that would have a 'settings' menu item that would be a > combo box to select a resource to associate with it. The output > would either be a filename or an abstract 'object handle' that the > plugin could convert to a filename. The filename would be > easiest, because the component would then became the thing that > converts between the handle and the filename. yes nice. but wait... how about an strcat component ? sample.wav / /the/path/ / \ / \ / strcat | | /the/path/sample.wav This would provide something like paths on the galan level... we could then provide a component emitting /the/path on every load... multiple paths would be an array of strings, which strcat would convert into an array of cat strings... sample component should try to load all strings in array... this is very easy to implement. But somewhat contrary to your proposal... ok back to the abstract object handle... the object handle component holds a reference on the resource... so pickeling it would save that to disk... > > Actually those two features would go a long way to making this dream > a possibility. Those are the current major weaknesses in galan as I > see them. yes you are right... > > * Bitmap or skinnable control panels were mentioned in passing. Torben > mentioned a background bitmap, but what I'm thinking is much more > than that. I'm thinking control panels and patch panel interfaces > akin to Propellerhead's Reason, but still keeping the core of galan. > > http://www.innotech-soft.com/seiten/propeller/screen.htm > > So a sheet could expose a more abstract control model, well I guess > it does actually, and then also provide a binding for a particular > graphical or 'skinned' control panel, front and back, so it'd be like > a rack componant. how are these interfaces set up ? the track me and david are now following tries to enable the user to build these skinned control panels like any other panel. the python track i began yesterday gives us more flexibility though. a skinned interface could be coded in python then... (and python code can be part of the project) > > This is really just an additional interface layer, and wouldn't > effect the internal operation of galan in the slightest, I'd think. > > > * Event sequencers. I mentioned these in a previous post. They would > be components with N output event pins that could produce a true event > on any given pin at any given step. They'd be like putting a bunch > of step sequencers in a row and only using one or two events on > them, but much more efficient. See my previous post for a better > description. They could be used to construct track-like sequencing, > too, by using their output pins to trigger playing and stopping of > step based sequencers. ah yes... > > * More visualization plugins would be nice. With more options. Not > only opengl, but VU-meters, histograms, and other visualization. yeah the visuals i have left them alone too long... > > I think an SDL-canvas control would be the best way to do this, > so you could make it as big as you want, and have it take simple > graph input and it'd graph it. And then all the above including the > current meter would simply send output to it. I know torben will say > 'opengl', but I honestly think SDL would be much faster. Perhaps a > componant that speaks an abstract graph protocol on one end and the > OpenGL or SDL protocols on the other would be the best way to do it. opengl and sdl on the output ? do i understand this right ? ok.. what can the graphing protocol do ? - paint bitmap at (x,y) - render this vektor interpolated onto box (x,y,w,h) - have a component scale/translate a (x,y,w,h) tuple... - hmm.. more does not come to my mind (this is already quite powerful... but having only 3 capabilities makes me think this protocol is too general) > > Incidently, I feel that an abstract graph protocol for drawing > visualization would aid in the advanced skinned control panels too. having thought about it i begin to believe what you feel :) > > * Loop sample players ala SpiralLoops: > > http://www.pawfal.org/Software/SpiralLoops/images/LoopsBig.png > > Torben mentioned opengl and such, I think it'd be better to just > make them regular high-level components with no opengl output. This > is really more of a loop control like our current one than a > visualization thing, except it'd be a littel easier for many people > to use. You are right.... one thing we have to solve though is play position is only known by the rart ATM... the sampler cant really display a "now playing" cursor... oh it can... the rart continously asks it for samples... these function must save the positions... nice... > > > Thats all I can think of right now. Mostly long term items, too. ok thanks... i hope david can contribute some thoughts also... -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language ----- End forwarded message ----- -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language |
From: Nick R. <ni...@fa...> - 2003-02-27 17:09:06
|
On Thu, Feb 27, 2003 at 07:48:14AM +0100, to...@gm... wrote: > nick, can you post some ideas and issues from our irc > sessions ? Lets see if I can dredge up the memories :) * My major desire is a sort of coherence in the save file system. Right now its totally sheet-based. This is fine for what we have, but to be really great I believe it needs to be project-based. What I mean by this is that the idea of a project needs to be inserted into galan. A project is composed of: * 1 or more sheets * 1 or more library paths (including the system sheet library path) * 1 or more resource lists (images, models, samples) * A tar file or path of resources * All the transient data associated with the controls such as patterns, settings on dials, etc. A project would need to be able to be exported as a 'project archive' that would be able to be distributed (so you could ensure that an entire project is transported when you distribute it, with all the required, samples and patterns and everything). The default project would be: * A blank sheet 'main' * The system library path * The system resource path Anyway. This is a major feature, probably some doing to impliment, but it could easily built in stages, as I see them: * THe ability to save transient data, either associated with all the sheets loaded or a particular sheet, to a file. I would think the ideal way to do this would be to add a savedata method to all the sheet objects that would serialize their internal storage to a stream or buffer. This is well along the lines of separating the assembly and arrangement of things from the data of things. Spirit and body. Sweet duality. * The ability to associate resources with abstract handles. This would work with a resource manager that would, for example, allow you to select a file, give the file an ID, and then a component that would have a 'settings' menu item that would be a combo box to select a resource to associate with it. The output would either be a filename or an abstract 'object handle' that the plugin could convert to a filename. The filename would be easiest, because the component would then became the thing that converts between the handle and the filename. Actually those two features would go a long way to making this dream a possibility. Those are the current major weaknesses in galan as I see them. * Bitmap or skinnable control panels were mentioned in passing. Torben mentioned a background bitmap, but what I'm thinking is much more than that. I'm thinking control panels and patch panel interfaces akin to Propellerhead's Reason, but still keeping the core of galan. http://www.innotech-soft.com/seiten/propeller/screen.htm So a sheet could expose a more abstract control model, well I guess it does actually, and then also provide a binding for a particular graphical or 'skinned' control panel, front and back, so it'd be like a rack componant. This is really just an additional interface layer, and wouldn't effect the internal operation of galan in the slightest, I'd think. * Event sequencers. I mentioned these in a previous post. They would be components with N output event pins that could produce a true event on any given pin at any given step. They'd be like putting a bunch of step sequencers in a row and only using one or two events on them, but much more efficient. See my previous post for a better description. They could be used to construct track-like sequencing, too, by using their output pins to trigger playing and stopping of step based sequencers. * More visualization plugins would be nice. With more options. Not only opengl, but VU-meters, histograms, and other visualization. I think an SDL-canvas control would be the best way to do this, so you could make it as big as you want, and have it take simple graph input and it'd graph it. And then all the above including the current meter would simply send output to it. I know torben will say 'opengl', but I honestly think SDL would be much faster. Perhaps a componant that speaks an abstract graph protocol on one end and the OpenGL or SDL protocols on the other would be the best way to do it. Incidently, I feel that an abstract graph protocol for drawing visualization would aid in the advanced skinned control panels too. * Loop sample players ala SpiralLoops: http://www.pawfal.org/Software/SpiralLoops/images/LoopsBig.png Torben mentioned opengl and such, I think it'd be better to just make them regular high-level components with no opengl output. This is really more of a loop control like our current one than a visualization thing, except it'd be a littel easier for many people to use. Thats all I can think of right now. Mostly long term items, too. -- -><- Nick Rusnov -><- http://nick.industrialmeats.com -><- ni...@fa.../nic...@de... |
From: <to...@gm...> - 2003-02-27 10:13:25
|
hi all.. first of all the HEAD revision in the cvs is now the 0.3.0 branch... but i am currently maintaining the 0.2.x branch... so you might want to do: cvs up -r GALAN-0-2 david konsumer sent me a nice patch which gets us on the track to making the Control Panel more compact: it is already in the GALAN-0-2 branch of the repository. you can select discreet now on a control... this hides the frame around a control. the label with the menu is still there, so you can still move the control and access the menu. i have implemented liblrdf support so if you have rdf files for your LADSPA plugins they are ordered into groups now. (no more browsing this stupid unstructured menu) i have now understood the event handling of XAP and think it would subtantly improve the galan eventhandling if it was done like in XAP... but i am still investigating how this can be done elegantly i.e. without changing much code... i also want to build a python module which makes galan accessible from python. i will be using pyrex for this task... also there was a bug in the 303vcf making its output silent if its input was silent also. This was the source of some pops you might have heard... this is also fixed in cvs... ok... i hope i can start a new thread on this list. it was so silent these days. nick, can you post some ideas and issues from our irc sessions ? -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language |
From: <to...@gm...> - 2003-01-15 18:03:54
|
Hi i have released galan-0.3.0-test1 this is the gtk+-2.0 version with jack support... there is still much todo but it is useable already so i released it... as a test Version... It would be nice to have a list of BUGS which i need to fix. so please report them... if the problem with the download server on sf.net persists i will continue the normal http distribution mechanism... |
From: Nick R. <ni...@fa...> - 2003-01-11 21:57:14
|
On Sat, Jan 11, 2003 at 09:19:10AM +0100, to...@gm... wrote: > After some silence caused by the huge workload i got from university > i have now released galan-0.2.12 > > for those of you who already use the cvs version there is not much new. > > i have recently only libtoolized galan... this should make it possible > to build on several architectures > > the semester will be over in less than a month so i am looking > forward to full +8h/day development in vacations. > > there needs to be a little tutorial on the opengl stuff... > i will try to describe it on the list first and give some examples > > the 0.3.0 shall be released the next days to see if anybody gets it compiled... > i need bugreports... Good to hear from you. I'll prepare the debian package later today. -- -><- Nick Rusnov -><- http://nick.industrialmeats.com -><- ni...@fa.../nic...@de... |
From: <to...@gm...> - 2003-01-11 20:36:59
|
hi After some silence caused by the huge workload i got from university i have now released galan-0.2.12 for those of you who already use the cvs version there is not much new. i have recently only libtoolized galan... this should make it possible to build on several architectures the semester will be over in less than a month so i am looking forward to full +8h/day development in vacations. there needs to be a little tutorial on the opengl stuff... i will try to describe it on the list first and give some examples the 0.3.0 shall be released the next days to see if anybody gets it compiled... i need bugreports... cu all |
From: torben h. <to...@gm...> - 2002-09-28 13:49:28
|
On 27 Sep 2002 10:35:19 -0700, Vonsur Kcin wrote: > On Fri, Sep 27, 2002 at 07:12:41PM +0200, torben hohn wrote: > > yeah... the null object is simple. > > like a box with a connector in it (there needs to be something with > > which you can drag > > the object around dragging with a connector does not work for obvious > > reasons) > > Hmm, I guess that it'd be okay. It would sort of mess up the look to > have all these little boxes but, eh, its fine. > > > the bus is cool too but i dont know how to implement that (out of my > > head) > > need to look at the code some more for a good idea. > > I was having trouble imagining how it'd work, it'd be way cool though. > > > How should sheet handling made better ? > > Well primarily the ability to save a sheet vs saving a project, the > idea that a project is composed of sheets that are separate entities. Sheet/Save if the sheet is referenced on another sheet it does not work. So in that case you would click Sheet/Unconnect first. But a dialog will tell you that. > > > No more registering (all sheets are available in sheet menu) ? > > All sheets in <directory> are in the new menu ? > > Well, if that directory were settable per project, or it were a group > of directories that you could edit in the project's properties. yeah... I need Project Properties. > > To be really useful the ability to save control settings as part of > the project, not as part of the sheet would be good, too. So all the > sheets remain pristine in the 'library', and the project keeps track > of the changes to the settings in them. yes. That would be very good. But this would require much code changes. At the moment there is Events/Settings this can be used nicely for saving settings in the synth. > If this were added, the ability to record the changes over time > wouldn't be that hard either. This is a really nice feature in, for > example, Fruityloops, and found in real synths like the Korg Electribes. well you can already use a midisequencer program to record such changes. i used vkeybd and seq24 here. the sequencer should be able to record. > > Also, 'library' sheets could be edited, and then saved along with the > project (eg, copied from the libary and saved with the changes made, > the data would still be separate). This functions allready if you load a sheet from a file it will be copied into your project File/Save now saves all sheets. (So this is the project) > > > My sheet library is growing i can make that available on the web-page. > > That'd be nice. It'd be nice to have an official sheet library as part > of the distribution in /usr/share/galan that is in the menu as > components that cant be added. s/cant/can/ what should be in there ? i currently have - drumbank - master sequencer - simple voice - filter + delay - sync osc (for nice basslines) > > > There is already Events/Timer > > I dont exactly know what you mean. > > timer emits the time between the last event and the current event. > > with some eventgates it should be possible to build almost any timing > > structure. > > > > try that or describe again... > > I want something that I can time the entire run time of the song with. > So, When I reset the sequencer and start recording to disk, I can see > how long I've been recording, so I know how many times to let it loop > and where I am within a song. you could first use the attached file to acomplish this > > So like a stop watch. It has an reset event in, start/stop event in, > time event out which is a value in ms, it has one control, which is the > time display, which displays in real time the number of hh:mm:ss:ms recorded. > Basically a stop watch. You can start and stop it at will, and poking the > reset pin will zero it. start and stop can be implemented into this with an Events/Gate having set tocomp to 1 a start button emitting 1 and a stop button emitting 0. These events can then also be declared as EvtIN and you have a working stopwatch. i hope you get a glance on what can be done with the Eventlogic plugins. These are also needed to process midi events. for example to decode the channel connector you connect an evtgate to channel and midiin the gate is open when the channel is equal to the ToComp value. > > This leads me to a gripe about the wav out. Its really hard to have it > start recording right at the beginning of the song, since you have to > reset the sequencer, or catch it right at the beginning when it loops > over. It'd be easier, or at least automatable, if you could specify > the output file that it would overwrite (saving a backup as > output.wav~), specified in a properties dialog in the same way that > wav in has a properties dialog. yeah that is a good idea. > > > The clock_rate is in Hertz which is steps per second. > > So if beat is every 4 steps > > BPM = clock_rate * 60 / 4; > > Right. > > > ok... i fixed that in the current code base. > > this is normally a missing call to gen_update_controls( g, > > control_number ) > > in the evt handler.... > > it is missing in many plugins.... > > I should probably look at all plugins if the function is called. > > Seems like a good idea. There are a lot of inconsistancies in the > plugins that can be cleaned up over time. I'll start keeping track. good. |
From: Vonsur K. <ni...@fa...> - 2002-09-27 17:35:22
|
On Fri, Sep 27, 2002 at 07:12:41PM +0200, torben hohn wrote: > yeah... the null object is simple. > like a box with a connector in it (there needs to be something with > which you can drag > the object around dragging with a connector does not work for obvious > reasons) Hmm, I guess that it'd be okay. It would sort of mess up the look to have all these little boxes but, eh, its fine. > the bus is cool too but i dont know how to implement that (out of my > head) > need to look at the code some more for a good idea. I was having trouble imagining how it'd work, it'd be way cool though. > How should sheet handling made better ? Well primarily the ability to save a sheet vs saving a project, the idea that a project is composed of sheets that are separate entities. > No more registering (all sheets are available in sheet menu) ? > All sheets in <directory> are in the new menu ? Well, if that directory were settable per project, or it were a group of directories that you could edit in the project's properties. To be really useful the ability to save control settings as part of the project, not as part of the sheet would be good, too. So all the sheets remain pristine in the 'library', and the project keeps track of the changes to the settings in them. If this were added, the ability to record the changes over time wouldn't be that hard either. This is a really nice feature in, for example, Fruityloops, and found in real synths like the Korg Electribes. Also, 'library' sheets could be edited, and then saved along with the project (eg, copied from the libary and saved with the changes made, the data would still be separate). > My sheet library is growing i can make that available on the web-page. That'd be nice. It'd be nice to have an official sheet library as part of the distribution in /usr/share/galan that is in the menu as components that cant be added. > There is already Events/Timer > I dont exactly know what you mean. > timer emits the time between the last event and the current event. > with some eventgates it should be possible to build almost any timing > structure. > > try that or describe again... I want something that I can time the entire run time of the song with. So, When I reset the sequencer and start recording to disk, I can see how long I've been recording, so I know how many times to let it loop and where I am within a song. So like a stop watch. It has an reset event in, start/stop event in, time event out which is a value in ms, it has one control, which is the time display, which displays in real time the number of hh:mm:ss:ms recorded. Basically a stop watch. You can start and stop it at will, and poking the reset pin will zero it. This leads me to a gripe about the wav out. Its really hard to have it start recording right at the beginning of the song, since you have to reset the sequencer, or catch it right at the beginning when it loops over. It'd be easier, or at least automatable, if you could specify the output file that it would overwrite (saving a backup as output.wav~), specified in a properties dialog in the same way that wav in has a properties dialog. > The clock_rate is in Hertz which is steps per second. > So if beat is every 4 steps > BPM = clock_rate * 60 / 4; Right. > ok... i fixed that in the current code base. > this is normally a missing call to gen_update_controls( g, > control_number ) > in the evt handler.... > it is missing in many plugins.... > I should probably look at all plugins if the function is called. Seems like a good idea. There are a lot of inconsistancies in the plugins that can be cleaned up over time. I'll start keeping track. -- -><- Nick Rusnov -><- http://nick.industrialmeats.com -><- ni...@fa.../nic...@de... |
From: torben h. <to...@gm...> - 2002-09-27 17:10:55
|
On 26 Sep 2002 11:02:58 -0700, Vonsur Kcin wrote: > > I had an interesting idea that would lead to some flexibility in the > network layout, mostly cosmetic. Have a 'bus' object, thats like a > long bar that distributes data to any point along it. It doesn't fit > into the current block and pin style thing, but It'd be useful for > laying out things. Basically there'd be a vertical and a horizontal > version, for events and signals. An alternative to this would be a > 'null' object, wich would jsut be the pad from a pin that you could > place anywhere you want, and connect wires to, so you could make right > angles at least, and event a bus-like thing. This would probably work > better within the 'galan wiring paradigm'. yeah... the null object is simple. like a box with a connector in it (there needs to be something with which you can drag the object around dragging with a connector does not work for obvious reasons) the bus is cool too but i dont know how to implement that (out of my head) need to look at the code some more for a good idea. > > Hrm, another idea I had was when the sheet system works better to be > able to impliment existing physical devices within gAlan, like classic > synths and sequencers and such, like Reason from Propellerhead does. > Actually in my mind gAlan is very close in possible application to > Reason, so it'd be cool to bring it to a point where it could replace > such software. Having classic synths and components in the 'sheet > library', once sheet management is a bit better, would be sweet, and > not that hard. not hard at all.. How should sheet handling made better ? No more registering (all sheets are available in sheet menu) ? All sheets in <directory> are in the new menu ? My sheet library is growing i can make that available on the web-page. > > A nice component would be a signal timer or some such. Maybe > associated with the sequence controller thing, so you know how long > your opus is stretching to. This could be a whole new component > actually, with a 'reset' pin antd button, and a display control, so > you slave it to the reset on the sequence controler. There is already Events/Timer I dont exactly know what you mean. timer emits the time between the last event and the current event. with some eventgates it should be possible to build almost any timing structure. try that or describe again... > > Another useful thing would be a BPM counter, or a 'BPM' format display > associated with the clock (what does the clock value mean, anyway? > steps per second? Hz? I can't correlate it with anything). The clock_rate is in Hertz which is steps per second. So if beat is every 4 steps BPM = clock_rate * 60 / 4; > > A bug I noticed was with LADSPA plugins. The controls on them don't > reflect programmatic changes occuring in them; for example if I hook > the feedback of a flanger up to a numeric sequence, the control for > that doesn't show the changes as they occur (or indeed at all), it > only shows what I previously set it to. Sort of annoying. ok... i fixed that in the current code base. this is normally a missing call to gen_update_controls( g, control_number ) in the evt handler.... it is missing in many plugins.... I should probably look at all plugins if the function is called. > > -- > -><- Nick Rusnov > -><- http://nick.industrialmeats.com > -><- ni...@fa.../nic...@de... > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Galan-list mailing list > Gal...@li... > https://lists.sourceforge.net/lists/listinfo/galan-list > |
From: torben h. <to...@gm...> - 2002-09-27 17:10:51
|
On 26 Sep 2002 07:39:42 -0700, Vonsur Kcin wrote: > On Thu, Sep 26, 2002 at 09:28:29AM +0200, torben hohn wrote: > > i have implemented support for libsndfile this library is better than > > libaudiofile. > > There are two plugins which are only build if libsndfile >= 1.0.0 is > > installed. > > These override the old voice and pcm_out. > > > the sndfile_in gives you 4 channel out connectors. > > Excellent. > > > is libsndfile in debian ? > > Yes, version 1.0 of it is in debian unstable at least. ok... then this will go into 0.2.12 > > > We are getting close to 0.2.12: i think i have added far too many > > features without release. > > Do you have a running list somewhere since .11? no... lets see... - GL stuff - selections - alsa midi - sndfile in out - iir_generic (lowpass, differentiate, integrate) hmm... bugfixes :-) dont know more... but there is some more... > > > I have noticed that old glib does not really support threads. > > For jack we need threading and therefor need glib-2.0 > > so i began the port to gtk+ 2.0 today. > > > what about gtk+ 2.0 in debian ? > > gtk+2.0 is in debian unstable as well. fine... i have a version with gtk+-2.0 which runs. the knob is not yet usable because of the gdk_pixbuf problems... and i am currently trying to make the ogg_ra threaded as my first thread experience. When that one works i will have a go on the audio thread. > > > i ran into problems with the new gdk_pixbuf_animation interface... > > But i think i will sort them out soon... i am awake for 1.5 hours now. > > Hehe. Good. did not sort them out :( but besides of that it works.. lets see what the gtk mailing lists say... > > > > It'd be nice to be able to select multiple controls like we can select > > > multiple objects to drag and manipulate :) > > > i think this will come after the gtk+ 2.0 port... > > For now i think the grouping of the controls is sufficient. > > I am more interrested in jack-output. > > Okay. > > Supporting Jack seems to be the way the winds are blowing, so its all > good. It seems like it'd allow integration with other audio projects > such as Ardour. yes... and with the gtk+-2.0 port i made a great step in that direction. > > hrm, I had a question about midi, though. > > What sort of midi support does galan have? I'm sort of a midi newbie, > so I don't really even understand how it works. External midi devices > can step-synchronize with galan's sequencers? Midi events <-> galan > events? There is a midi clock it ticks like a normal clock. so you can clock a sequencer from a midi device. Also midi events are converted to galan events. the alsa midi can inside your computer there is vkeybd for example a program which is only a keyboard. this can be connected to a galan synth for example.... i will add an example soon... i am also thinking about a doc component (can be filled with text no more) So that one can document the galan-sheet. Also with gtk+-2.0 there could be a text containing widgets( controls ) so that the interface of the synth is embedded in the text documenting it. well... only 1 week left till start of studies... which will slow me down... until then full speed ahead :) > > Thanks. > > -- > -><- Nick Rusnov > -><- http://nick.industrialmeats.com > -><- ni...@fa.../nic...@de... > |
From: Vonsur K. <ni...@fa...> - 2002-09-26 18:03:01
|
I had an interesting idea that would lead to some flexibility in the network layout, mostly cosmetic. Have a 'bus' object, thats like a long bar that distributes data to any point along it. It doesn't fit into the current block and pin style thing, but It'd be useful for laying out things. Basically there'd be a vertical and a horizontal version, for events and signals. An alternative to this would be a 'null' object, wich would jsut be the pad from a pin that you could place anywhere you want, and connect wires to, so you could make right angles at least, and event a bus-like thing. This would probably work better within the 'galan wiring paradigm'. Hrm, another idea I had was when the sheet system works better to be able to impliment existing physical devices within gAlan, like classic synths and sequencers and such, like Reason from Propellerhead does. Actually in my mind gAlan is very close in possible application to Reason, so it'd be cool to bring it to a point where it could replace such software. Having classic synths and components in the 'sheet library', once sheet management is a bit better, would be sweet, and not that hard. A nice component would be a signal timer or some such. Maybe associated with the sequence controller thing, so you know how long your opus is stretching to. This could be a whole new component actually, with a 'reset' pin antd button, and a display control, so you slave it to the reset on the sequence controler. Another useful thing would be a BPM counter, or a 'BPM' format display associated with the clock (what does the clock value mean, anyway? steps per second? Hz? I can't correlate it with anything). A bug I noticed was with LADSPA plugins. The controls on them don't reflect programmatic changes occuring in them; for example if I hook the feedback of a flanger up to a numeric sequence, the control for that doesn't show the changes as they occur (or indeed at all), it only shows what I previously set it to. Sort of annoying. -- -><- Nick Rusnov -><- http://nick.industrialmeats.com -><- ni...@fa.../nic...@de... |
From: Vonsur K. <ni...@fa...> - 2002-09-26 14:39:45
|
On Thu, Sep 26, 2002 at 09:28:29AM +0200, torben hohn wrote: > i have implemented support for libsndfile this library is better than > libaudiofile. > There are two plugins which are only build if libsndfile >= 1.0.0 is > installed. > These override the old voice and pcm_out. > the sndfile_in gives you 4 channel out connectors. Excellent. > is libsndfile in debian ? Yes, version 1.0 of it is in debian unstable at least. > We are getting close to 0.2.12: i think i have added far too many > features without release. Do you have a running list somewhere since .11? > I have noticed that old glib does not really support threads. > For jack we need threading and therefor need glib-2.0 > so i began the port to gtk+ 2.0 today. > what about gtk+ 2.0 in debian ? gtk+2.0 is in debian unstable as well. > i ran into problems with the new gdk_pixbuf_animation interface... > But i think i will sort them out soon... i am awake for 1.5 hours now. Hehe. Good. > > It'd be nice to be able to select multiple controls like we can select > > multiple objects to drag and manipulate :) > i think this will come after the gtk+ 2.0 port... > For now i think the grouping of the controls is sufficient. > I am more interrested in jack-output. Okay. Supporting Jack seems to be the way the winds are blowing, so its all good. It seems like it'd allow integration with other audio projects such as Ardour. hrm, I had a question about midi, though. What sort of midi support does galan have? I'm sort of a midi newbie, so I don't really even understand how it works. External midi devices can step-synchronize with galan's sequencers? Midi events <-> galan events? Thanks. -- -><- Nick Rusnov -><- http://nick.industrialmeats.com -><- ni...@fa.../nic...@de... |
From: torben h. <to...@gm...> - 2002-09-26 07:26:46
|
On 20 Sep 2002 09:18:55 -0700, Vonsur Kcin wrote: > > > Also, it'd be nice if that plugin supported multichannel wavs. Hrm. > Maybe break it into a 'raw' sample plugin, a wav plugin that supports > one or more channels? I know its probably not easy to have a plugin > change the number of out pins it has... maybe just support four > channels maximum or something, with that many outputs. Wait, the > intersheet objects can set the number of pins they have, so I don't > really see an issue. One random access out per channel. The same for > ogg and mp3 and whatever else. i have implemented support for libsndfile this library is better than libaudiofile. There are two plugins which are only build if libsndfile >= 1.0.0 is installed. These override the old voice and pcm_out. the sndfile_in gives you 4 channel out connectors. is libsndfile in debian ? We are getting close to 0.2.12: i think i have added far too many features without release. I have noticed that old glib does not really support threads. For jack we need threading and therefor need glib-2.0 so i began the port to gtk+ 2.0 today. what about gtk+ 2.0 in debian ? i ran into problems with the new gdk_pixbuf_animation interface... But i think i will sort them out soon... i am awake for 1.5 hours now. > It'd be nice to be able to select multiple controls like we can select > multiple objects to drag and manipulate :) i think this will come after the gtk+ 2.0 port... For now i think the grouping of the controls is sufficient. I am more interrested in jack-output. > > Eh, probably other stuff that I can't think of right now. > > The latest CVS is looking great though. Thanks. thanks :) |
From: torben h. <to...@gm...> - 2002-09-22 21:13:19
|
On 20 Sep 2002 09:18:55 -0700, Vonsur Kcin wrote: > > Hrm, there is something particularly annoying, if you load 2oggplayers > from the examples, a segmentation fault happens when it can't find the > files refered to in it. IMHO it should simply ignore that the file is > missing like the 'Sampled voice' plugin. Its really annoying to have > galan segfault on startup because it can't find a sample. hmm... i dont get that segfault :( please try the attached doubleogg.. |
From: torben h. <to...@gm...> - 2002-09-22 15:30:39
|
On 20 Sep 2002 09:18:55 -0700, Vonsur Kcin wrote: > > Hrm, there is something particularly annoying, if you load 2oggplayers > from the examples, a segmentation fault happens when it can't find the > files refered to in it. IMHO it should simply ignore that the file is > missing like the 'Sampled voice' plugin. Its really annoying to have > galan segfault on startup because it can't find a sample. oh... yes.. i have not noticed that. will be fixed... > > Speaking of the ogg_ra plugin ... Its pretty annoying how it works. I yes.. but.... > don't know why I have to worry about buffer and such beyond a but you have this encapsulated in a sheet. if we had a sheet library you would load the oggplayer sheet (dont look at it) and simply connect that. > 'properties' page. I personally would prefer a sampled voice > plugin-like thing, eg the properties page allows you to select a file, > and you simply hook it up to a ra->stream converter and go. Having the > end-of-file event out is good, though, should add that to the other > 'file in' ones (currently only 'Sampled Voice'). Or would it make more > sense to have the ra->stream converter have an 'end of sample' event > out? ra->stream converter should send the signal. what about playlists ? if you set the filename via the properties it is out of reach from other components of the galan mesh. i also wanted to make the file name of the sampled voice an input connector. (The properties to set the filename can remain) how about skipping and pithing ? these issues are not supported by the rart ATM. So i implemented that in gAlan and made the interface of the plugin like it is now. if we find a way how to support skipping and pitching with the rart i would be happy to remove the buffering stuff... > > Also, it'd be nice if that plugin supported multichannel wavs. Hrm. > Maybe break it into a 'raw' sample plugin, a wav plugin that supports > one or more channels? I know its probably not easy to have a plugin > change the number of out pins it has... maybe just support four > channels maximum or something, with that many outputs. Wait, the yeah... i will add those three connectors. > intersheet objects can set the number of pins they have, so I don't > really see an issue. One random access out per channel. The same for > ogg and mp3 and whatever else. Intersheet Objects are not generators. They are only components. The generators register a class and in this class it is set how many pins they have. also if it were possible to have the component change its connectors what would happen if you had a 4 channel wav loaded, loaded a two channel wav, and then a 4channel again. loading the 2 channel would remove 2 connectors and their connections. loading the 4 channel would add the connectors but the connections would have been forgotten. nah... i would rather add 8 connectors than making them dynamic. > > Hmm some more notes: > > It seems like the Patern Loop control should show which pattern its in > (eg 0 or 1 or 2), which position in the pattern list (eg, a, b, c to > indicate the first, second, third part of the pattern list) and which > position in that pattern (eg 0..32, the 'lights' offset basically). the first number is the listentry which is currenlty played. the second is the pattern position. but since the audio is delayed and the display not it looks strange. > The current clock on this control is useless. It doesn't show real > time, thats for sure.. I don't really understand what its showing. In > folded mode it should show just the playing position. yeah... i have to implement some callbacks for setting folding mode on user defined controls to support that. But that should be easy. > > It'd be nice to be able to select multiple controls like we can select > multiple objects to drag and manipulate :) yes... i will have a look on how i can draw on a GtkFixed Widget. to draw the selection box. also need to change the color of a GtkLabel to indicate selection. > > Eh, probably other stuff that I can't think of right now. > > The latest CVS is looking great though. Thanks. > > nick > > -- > -><- Nick Rusnov > -><- http://nick.industrialmeats.com > -><- ni...@fa.../nic...@de... > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Galan-list mailing list > Gal...@li... > https://lists.sourceforge.net/lists/listinfo/galan-list > |