| Author |
Message |
Axiom
Joined: Feb 19, 2005
Posts: 288
Location: Italy
Audio files: 4
G2 patch files: 28
|
 Posted: Sat Mar 26, 2005 6:58 pm Post subject:
Modular SDK |
  |
|
I think that can be very nice if we can realize our own modules. I've seen something similar in SynthEdit and Creamware Pulsar.
see ya
_________________
  |
|
|
Back to top
|
|
 |
LLR3
Joined: Sep 10, 2004
Posts: 41
Location: Helsinki Finland
|
| Posted: Sat Mar 26, 2005 7:04 pm Post subject:
|
|
|
Check the previous topic (the zero page thing): We suggested programmability feature only one minute apart without knowing of each other!!!
*LLR3
[editor's note: he means here: http://electro-music.com/forum/topic-5801.html - mosc] |
|
|
Back to top
|
|
|
Rob
Joined: Mar 29, 2004
Posts: 580
Location: The Hague/Netherlands/EC
G2 patch files: 109
|
| Posted: Sun Mar 27, 2005 6:50 am Post subject:
Re: Modular SDK |
|
|
| Axiom wrote: | I think that can be very nice if we can realize our own modules. I've seen something similar in SynthEdit and Creamware Pulsar.
see ya |
I remember that already on the NM1 there was a discussion on the possibility of a 'scripting module', a module where a simple script could be written and that would compile to dsp code on patch load. Most wanted feature of such a script was to be able to dimension small arrays. Such a module could have some inputs and one or more outputs that would show as 'predefined' variables in the scripts. Indexing in arrays of values is quite a powerful feature in both synthesis and algorithmic composing and would add tremendous power to the G2.
Some additional simple algebraic, trigonometric and logic operators would be the icing on the cake. And of course an If-Then and a Case switch. Imho, the If-Then could simply listen to a yellow input, as the conditions are probably defined somewhere else in the patch and this way the If-Them would act as trigger/gate for the scripted function.
My personal preference would be to have a Forth-like scripting language. Not only because a Forth-like approach would probably perform very well in speed and code memory useage, but also because it is very powerful in defining events for musical use. I know, as I used Forth extensively for composing during the eighties. It is very easy and intuitive to define a specific musical event or string of musical events as a single Forth command that can be started by a single trigger. Which in the G2 case would translate to one script in one scripting module for this event or string of events. Need I say more? |
|
|
Back to top
|
|
|
mosc
Site Admin
Joined: Jan 31, 2003
Posts: 18235
Location: Durham, NC
Audio files: 222
G2 patch files: 60
|
| Posted: Sun Mar 27, 2005 8:19 am Post subject:
|
|
|
This scripting module would be great. I've never used forth, but eveyone I know who has used it would agree with you.
I can see lots of problems with this from an implimentation perspective. Do the patches store both the complied code and the scripts?
_________________
--Howard
my music and other stuff |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Sun Mar 27, 2005 9:45 am Post subject:
|
|
|
Yay, arrays!
I vote for Lisp.
(lisp is exceptionally good at doing stuff to arrays, it also has a long history of being used for music).
Erm, but let´s be honest here. Each and every problem the G2 has could be fixed by simply moving to a computer and getting something along the lines of Csound or SuperCollider. This will get you better sound, no zero page limit, and in the case of Csound even removes the limitations of being realtime (which i´ve become convinced is simply not fast enough). Through OSC you could interface to a programing language of your choice if those languages aren´t elaborate enough for some reason. They are cheaper too, much cheaper, infinitely much more so, in fact.
The only thing the G2 has over these things is the interface which is realy pleasant to use for some simple things. This is a small but desicive advantage, a large enough advantage to actually use the G2, luckily for Clavia.
If we start adding scripts we are losing this. Proper programing is more powerfull then building it all using logic modules, using any of the other modules wouldn´t make sense anymore, except for convenience.
Let´s admit the pupose of the G2 and use it for that or move on.
_________________
Kassen |
|
|
Back to top
|
|
|
jamos
Joined: Jun 01, 2004
Posts: 514
Location: Eugene, Oregon, USA
Audio files: 4
G2 patch files: 41
|
| Posted: Sun Mar 27, 2005 9:53 am Post subject:
|
|
|
| Quote: | | Let´s admit the pupose of the G2 and use it for that or move on. |
Hear, hear!
The G2 is fantastic for what it is. When it grows, I hope it grows in the same direction, rather than in completely new directions. |
|
|
Back to top
|
|
|
Rob
Joined: Mar 29, 2004
Posts: 580
Location: The Hague/Netherlands/EC
G2 patch files: 109
|
| Posted: Sun Mar 27, 2005 10:28 am Post subject:
|
|
|
| mosc wrote: | | I can see lots of problems with this from an implimentation perspective. Do the patches store both the complied code and the scripts? |
Patches should store the scripts, to enable them to be edited later on another machine. Compilation should be either on patchload or when the script edit window for that scripting module is closed. So, a script compiler should be incorporated into the G2 firmware. Imho it wouldn't be that hard to implement. E.g. the code to get a sine value is already present in the triangle to sine converters in the oscs. Division would of course pose the division by zero error problem, but for practical purposes this could be solved by having a division by zero result just default to either the positive or negative headroom level. As a valid division result that exceeds the headroom level should be clipped to headroom level as well.
Personally I think I would be happy with:
add(x,y)
subtract(x,y)
mul(x,y)
div(x,y)
neg(x), which negates x
abs(x)
muldiv(x,y,z), which first multiplies z by x and immediately divides the 48-bit result by y
mod(x,y), where y is the modulo boundary that folds back to -y
wrap(x,y), where y is the positive and negative wrap-around modulo (not unlike the wave wrapper, but the output range would be between -y and y. Which is more convenient when manipulating array indices)
sin(x)
tan(x)
rnd(x), where x is the seed
1/(x), for the infamous "one over f"
greater(x,y), yields the greatest of the two
smaller(x,y), yields the smallest of the two
maskbit(x,y), yields 0 or 1 if bit y in x is set or not
setbit(x,y,z), sets bit y in x to z (z = 0 or 1)
flipbit(x,y,z), exor bit y in x with z (z = 0 or 1)
boundary(x,y,z), which tests if the difference between x and y is smaller or greater than z, and results in 0 or 1
int(x,y), where x is quantized to y units steps
frac(x,y), which should yield the remainder of the int(x,y) function
dim(a,x), which allocates an array with name a and length x
var(a), which creates a variable with the name a
Z-1(a), which yields the value that variable a had at the previous calculation round
write(array,x,y), where y is stored at position x in an array
read(array,x), which yields the value at position x in an array
Note! if the location index exceeds the array length the index should automatically wrap around the array length instead of generating an error
conditional switch construct:
switch(x), where x is used to define code segment to jump to
case(l,h) l=lowest window boundary, h=highest window boundary (If x in switch(x) is between l and h the following code segment in the switch construct is executed)
case else, for all other cases
end switch, to define the end of the switch construct
Note! switch(x) is vaguely similar to what happens in the KeyQuant, but can be extended over any number of choices. Obvious musical use is to make scales that extend that one octave of the KeyQuant. But it can do much more complex things by conditional execution of larger and differing script segments.
The main issue is that there should be no execution-time errors, like the infamous 'divide by zero illegal operation' or when indexing outside an array. So, overflows should just produce the min and max headroom values, like the modules do now. Exceeding index ranges should just wrap indices back into the defined index ranges (which btw is a great way to produce hardsync with a single osc). If this is well-documented then there shouldn't be run-time problems.
I would have no problem with only one statement on a line.
The DSP can execute 150.000.000/96.000 instructions per calculation round. Which means a little over 1500 instructions are available within the 100% dsp resources. If a scripting module would use 50% dsp and there were fifty lines there would be an average of 750/50 = 15 dsp instructions per line/statement. I guess that is enough for a simple statement.
Obviously (and regrettably) recursion would not be possible.
I would already be happy with only one or two predefined arrays per scripting module. I would suggest a max length of array of 512 locations, so the index can be between -256 and 255 units. An idea could be to have a simple compiler directive at the start of the script, which defines if there is a single array between -256 and 255 or two arrays between 0 and 255.
If the scripting module had e.g. four signal inputs, four knobs, four name buttons and one output, these could be predefined as variables I1, I2, I3, I4, K1, K2, K3, K4, B1, B2, B3, B4 and O.
Additionally I can imagine a yellow input and a trigger/gate button. When in trigger mode the compiled script is only executed on a positive flank trigger, and when in gate mode the module is only executed while the gate is on.
When the yellow input is unconnected the module is always calculated.
Maybe it could do with a sample rate button as well, so the red or blue mode can be forced by this button, instead of making it depending on the rate of the input signals. E.g. for algorithmic composing the blue sample rate would probably always do, no matter if red signals are connected to the inputs. But for synthesis it might be desirable to run the module at 96kHz, even if there are only blue signals connected.
Personally I would care less about the math functions except for the modulo functions, but care a lot about the arrays. As that is the thing that is really missing in the G2 system.
A simple Edit button on the module could open the script editor and a Close button in the script editor could go back to normal mode after recompiling the script to dsp code.
Well, this is sort of my two cents on the subject. |
|
|
Back to top
|
|
|
Roland Kuit
Joined: Sep 29, 2003
Posts: 1090
Location: The Netherlands/Sweden
Audio files: 8
G2 patch files: 127
|
| Posted: Sun Mar 27, 2005 10:29 am Post subject:
|
|
|
| I composed with Forth too, but i prefer Lisp. Would be nice such a module, whatever language it would be. |
|
|
Back to top
|
|
|
Rob
Joined: Mar 29, 2004
Posts: 580
Location: The Hague/Netherlands/EC
G2 patch files: 109
|
| Posted: Sun Mar 27, 2005 10:59 am Post subject:
|
|
|
| Kassen wrote: | Yay, arrays!
I vote for Lisp.
(lisp is exceptionally good at doing stuff to arrays, it also has a long history of being used for music).
Erm, but let´s be honest here. <snip>
|
Of course you are right.
But what is important here is a matter of scale, a rather small albeit practical scale when the G2 is concerned. A scripting module could probably never be more than a convenience module, to quickly and conveniently define e.g. a modulo function when it is needed. Or conveniently store some values to be recalled later. Which occurs to me is hardly the scale that your comment on Lisp, CSound et al seems to suggest.  |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Sun Mar 27, 2005 11:22 am Post subject:
some realy modest proposals that can´t do any harm. |
|
|
I´m mostly with you, Rob, but I´m kinda attached to recursion (which explains my preference for Lisp, a language so deeply related to recursion that it arguably had it´s break-even point *before* it´s first interperter was written). We could simply have recursion and damned if it doesn´t get done it time, you´d just have the thing throw a pulse ones it´s done and add a s&h.
Actually you´d need to write the language speciffically for that purpose in order to keep some people from using recursion. this set here isn´t. (unless "switch" is only allowed to go to segments of code later on which admittedly would simplify things considerably).
I´m not realy sure I´m interested if we are not going to have recursion.
About those arrays, I think that if the lookup pointer goes out of range then the array should return the last or first value in the array instead of wrapping. In addition to this there should be either a query that returns the length of any given array. This means a mod function can take care of the wrapping if wrapping is needed. The other way around is much harder but also usefull.
I would realy, realy, like to be able to treat arrays, operators and variables as values that can be written to arrays. That need not be documented and I´m perfectly fine with error messages whenever this generates problems because we accidentally tell the parser to multiply a variable with a operator.
I´d like a Labda function too, at the very least i´d like a way of placing something in brackets and the option of using mathematical expresions involving variables instead of variables themselves.
These things realy can´t do that much harm outside of their box and with this set of features you are not going to keep people from implementing their own anyway through lots of pain and roundabout methods so you might as well make it easy for them.
We need logic operators within this too, there´s realy no good reason to keep those away.
If we have conditional expressions then predicting how much dsp the module will cost is going to be hard if not impossible, A better idea, imho, would be to have the user asign some amount to it and accept it might not get done in time. It´s going to alias like a double agent on pcp anyway.
I´d like variables to be able to store words or at least letters, then have a way of writing to the lcd displays.
But, wouldn´t it be much better to tunnel OSC through the usb port with a realy simple translator module, then do all of this externally?
_________________
Kassen |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Sun Mar 27, 2005 11:36 am Post subject:
|
|
|
| Rob wrote: |
But what is important here is a matter of scale, a rather small albeit practical scale when the G2 is concerned. A scripting module could probably never be more than a convenience module, to quickly and conveniently define e.g. a modulo function when it is needed. Or conveniently store some values to be recalled later. Which occurs to me is hardly the scale that your comment on Lisp, CSound et al seems to suggest. |
Well, yes and no. As I mentioned previously; I´ve never ever run into the dsp limit of the G2 but keep bumping into the zero page for my little analogue computers. If we have readable and writable arrays we have a Turning machine which inherently means "all hell breaks loose".
Scale is a very relative matter. We have a dsp chip that eats only gates and values, on top of it we build a graphical interface that in turn involves logic gates. Now we are debating wether it woudn´t be nice to have some "normal" programing next to that.....
What I mean to point out is that if scripting is considered convenient, more convenient actually then programing whatever function is needed using gates and memory cells then we are barking up the wrong tree.
_________________
Kassen |
|
|
Back to top
|
|
|
Rob
Joined: Mar 29, 2004
Posts: 580
Location: The Hague/Netherlands/EC
G2 patch files: 109
|
| Posted: Sun Mar 27, 2005 11:49 am Post subject:
Re: some realy modest proposals that can´t do any harm. |
|
|
Some valuable additional suggestions from you, Kassen.
My idea of the Switch(x) was to indeed make it simple and only let it branch forwards. By providing the (x) there the jumps can probably be calculated with one conditional test that causes a jump forward, instead of having to do the conditional test for every case statement later on.
I thought about logic operators, my thought was to keep it simple by being able to extract and manipulate bits in array values and do the logic with the standard logic modules. A 256 length 24 bit array could that way simply double as a two dimensional 256 by 24 array of event bits. But this might call for extra outputs on the scripting module, so perhaps it is best to have them as scripting functions.
This variable text to write to displays would be quite nice indeed.
Anyway, its all dreaming.
And yes, OSC support through USB is such a good suggestion that it deserves its own Wish list thread. Imho, it is especially innovative companies like Clavia that should start implementing OSC in 'standard' musical instruments. The G2 is the ideal instrument to start with. |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Sun Mar 27, 2005 11:50 am Post subject:
|
|
|
| jamos wrote: | | Quote: | | Let´s admit the pupose of the G2 and use it for that or move on. |
Hear, hear!
The G2 is fantastic for what it is. When it grows, I hope it grows in the same direction, rather than in completely new directions. |
I´d like it to first go back to the purity of the G1, speciffically the rack, stylistically. The very last thing it should do imho is "grow" even further in the "G2 direction". As I mentiopned, I already have to defend Clavia when friends describe their equipments as "only suitable to make trance on".
I´m alone in this, I fear.
_________________
Kassen |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Sun Mar 27, 2005 12:08 pm Post subject:
Re: some realy modest proposals that can´t do any harm. |
|
|
| Rob wrote: |
Some valuable additional suggestions from you, Kassen.
|
Why thank you, they weren´t realy well thought out because aside from tunings i´m not realy sure what I´d do with them. I just thought I´d ask for recursion and Labda operators and make sure that I could when I´d discover what I want. There are several truely elegant proofs for this, etc.
;¬)
Let´s not fight over this because I´m simply not going to agree with anything that´s not arguably a dialect of Lisp and that oozes recursion and will turn you brain inside out if you aproach it from a perspective where time is relevant.
If I can tunnel OSC through the USB (at the expense of those other three G2´s, presumably) then I´ll be happy enough for now. However, in that case I´m going to have to insist on the option of data making clear from what voice it comes or what voice it´s adressed to. In that last case I think it´d be acceptable and indeed advisable to wrap.
Actually that will instantly enable my deeply desirered inter-voice comunication without using modems and the asociated bandwith problems, bus costs, etc. blah blah blah and so on and so forth.
too much coffee to little food.
_________________
Kassen |
|
|
Back to top
|
|
|
Rob
Joined: Mar 29, 2004
Posts: 580
Location: The Hague/Netherlands/EC
G2 patch files: 109
|
| Posted: Sun Mar 27, 2005 12:16 pm Post subject:
|
|
|
| Kassen wrote: |
What I mean to point out is that if scripting is considered convenient, more convenient actually then programing whatever function is needed using gates and memory cells then we are barking up the wrong tree. |
To clarify my point of view on convenience a bit more:
Right now its hell to do even the simplest form of array processing. Programming functions like a simple increment/decrement counter with adjustable output range is hell as well. Mostly because the patches start to look obscure and zero page memory quickly hits the rooftop. Any improvement that can be made here is convenient to me, even the slightest improvement. So, best is to take the G2 itself as the reference and try to see where to go from there without falling into the 'the grass is always greener at the neighbours' trap.
Point is that if this suggested type of module is supported by a large amount of the G2 community to be a serious wish, solid argumentation will be needed, hard and solid as swedish steel. It needs to be discussed well and the final suggestion should be implementable without too much trouble in the current system. It also should basically fit the current design philosophy, otherwise I'm pretty sure we can shake it. And it should solve current issues, like e.g. the zero page/outputs issue or the lack of even the simplest arrays, which basically means it should indeed literally be a 'convenient' module in lots of situations. And in a way also sort of a last resort, if patching becomes too complex or too obscure then perhaps the scripting module can solve it. And not a 'let's start a new patch with a scripting module and see how fast the script can go to 100% dsp'. Then it would miss the point completely and Clavia would simply never implement it. |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Sun Mar 27, 2005 12:38 pm Post subject:
|
|
|
Yah, that´s basically what i´m saying, but if we *are* going to script it´d better be good.
Anyway, with a read head, a write head, modulation for both and a mod function we´d be in business. Simple module, three inputs, one setting for the length and two ouptuts (one of which returns the thing´s length so we can use that with a mod function or scale depending on that.)
Doing OSC through the USB line would take care of the real scriptin, a.i. and so on externally where it can´t hurt anybody´s head accidentally, cause horrible aliassing or cause divide by zero errors. I´ll do my Labda-ing in secret.
doesn´t that sound suspiciously reasonable?
_________________
Kassen |
|
|
Back to top
|
|
|
LLR3
Joined: Sep 10, 2004
Posts: 41
Location: Helsinki Finland
|
| Posted: Sun Mar 27, 2005 4:14 pm Post subject:
|
|
|
PROGRAMMABLE CONTROL MODULE
My initial idea was to build on Clavia designs, not to try replacing theirs. Therefore the system that I propose is a programmable module for CONTROLLING other modules - not for generating or processing AUDIO. So just for the sake of simplicity, all audio processing in this model is left to external modules made by Clavia. The present module set will serve as a good starting point here and perhaps only this one new module would be needed in the beginning...
Enter the PCM
PCM´s should appear as regular modules on the editor except that their size would vary according to the number of labeled inputs, outputs, knobs, buttons and some basic state indicators (such as leds and simple alphanumeric displays) etc. Well let´s say in the first release there´d really only have to be labeled inputs and outputs. The rest is extra and could be added later. Being able to build proper interfaces on the virtual front panels would be nice, but not absolutely necessary in the first releases. (Remember, this is just a dream!)
...
I´m afraid I´m so badly behind schedual on other important things that I´ll have jump on to commenting Rob´s (excellent!) proposition for G2 scripting system. I´ll keep working on the subject and will publish some more thoughts on it later (here)...
| Rob wrote: | | Patches should store the scripts, to enable them to be edited later on another machine. Compilation should be either on patchload or when the script edit window for that scripting module is closed. So, a script compiler should be incorporated into the G2 firmware. |
I agree with that.
| Rob wrote: | | Imho it wouldn't be that hard to implement. E.g. the code to get a sine value is already present in the triangle to sine converters in the oscs. Division would of course pose the division by zero error problem, but for practical purposes this could be solved by having a division by zero result just default to either the positive or negative headroom level. As a valid division result that exceeds the headroom level should be clipped to headroom level as well |
Perhaps depending on the sign of the previous VALID divisor value the result could be set either to the positive or to the negative headroom limit?
| Rob wrote: |
The main issue is that there should be no execution-time errors, like the infamous 'divide by zero illegal operation' or when indexing outside an array. So, overflows should just produce the min and max headroom values, like the modules do now. Exceeding index ranges should just wrap indices back into the defined index ranges (which btw is a great way to produce hardsync with a single osc). If this is well-documented then there shouldn't be run-time problems. |
Array sizes could be set as power of two so that only the most significant bits of an array index pointer would be used to access the table.
| Rob wrote: | | I would have no problem with only one statement on a line. |
This sort of arrangement I was thinking of myself as well. Simple better say Tarzan!
| Rob wrote: | | The DSP can execute 150.000.000/96.000 instructions per calculation round. Which means a little over 1500 instructions are available within the 100% dsp resources. If a scripting module would use 50% dsp and there were fifty lines there would be an average of 750/50 = 15 dsp instructions per line/statement. I guess that is enough for a simple statement. |
I was thinking that the execution frequency of the scripting module should be freely selectable. If a cycle would be set longer, more could be done within it. Naturally longer programs would occupy more space anyway...
| Rob wrote: | | Obviously (and regrettably) recursion would not be possible. |
Execution time for the code block should be exactly the same on every cycle so we´d have to evaluate the time consumption in all conditional processing according to worst case scenarios. I´m not sure what to think of jumping around for the sake of code re-use but other than that and some simple conditional branching I think the execution path should be as straight as possible.
| Rob wrote: | | I would already be happy with only one or two predefined arrays per scripting module. I would suggest a max length of array of 512 locations, so the index can be between -256 and 255 units. An idea could be to have a simple compiler directive at the start of the script, which defines if there is a single array between -256 and 255 or two arrays between 0 and 255 |
I´d like to have an option to use multi dimensional arrays even if the total number of array elements would be limited.
| Rob wrote: | If the scripting module had e.g. four signal inputs, four knobs, four name buttons and one output, these could be predefined as variables I1, I2, I3, I4, K1, K2, K3, K4, B1, B2, B3, B4 and O.
Additionally I can imagine a yellow input and a trigger/gate button. When in trigger mode the compiled script is only executed on a positive flank trigger, and when in gate mode the module is only executed while the gate is on.
When the yellow input is unconnected the module is always calculated.
Maybe it could do with a sample rate button as well, so the red or blue mode can be forced by this button, instead of making it depending on the rate of the input signals. E.g. for algorithmic composing the blue sample rate would probably always do, no matter if red signals are connected to the inputs. But for synthesis it might be desirable to run the module at 96kHz, even if there are only blue signals connected. |
Triggered events would result in unpredictable consumption of execution cycles. I think the code block(s) should be continuously executed on a constant rate.
| Rob wrote: | | Personally I would care less about the math functions except for the modulo functions, but care a lot about the arrays. As that is the thing that is really missing in the G2 system. |
What sort of math functions are you referring to? I´m not after anything fancy either - the basic stuff would do just fine.
| Rob wrote: | | A simple Edit button on the module could open the script editor and a Close button in the script editor could go back to normal mode after recompiling the script to dsp code. |
Yes I agree, something along those lines.
| Rob wrote: | | Well, this is sort of my two cents on the subject. |
I think I could make a more thorough proposal on how this thing should in my view be implemented but now I really have to concentrate on something else...
*LLR3 |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Sun Mar 27, 2005 4:54 pm Post subject:
|
|
|
That sounds like what Tassman does with "sub patches", this works realy well, I think. I made some of my own ideas in there and ported a few NM and G2 modules I like. It´s realy usefull and timesaving and does wonders for how easy to grasp complex patches are, provoded your modules are bug free.
_________________
Kassen |
|
|
Back to top
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004
Posts: 24392
Location: The Netherlands, Enschede
Audio files: 296
G2 patch files: 320
|
| Posted: Sun Mar 27, 2005 5:34 pm Post subject:
|
|
|
How about a much simpler model, state machines ?
Jan. |
|
|
Back to top
|
|
|
jksuperstar
Joined: Aug 20, 2004
Posts: 2503
Location: Denver
Audio files: 1
G2 patch files: 18
|
| Posted: Sun Mar 27, 2005 10:48 pm Post subject:
|
|
|
| Very good one, Jan. The JK flop and sequencer modules don't quite cut it for explorations into more Artificially Intelligent patches. But this would also be implemented most effectively as a scripting module though, unless you have more specific ideas? |
|
|
Back to top
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004
Posts: 24392
Location: The Netherlands, Enschede
Audio files: 296
G2 patch files: 320
|
| Posted: Mon Mar 28, 2005 6:18 am Post subject:
|
|
|
I was thinking that we might never have a true scripting module as this might be too complex to fit in. Also a scripting language is a bit of an odd thing to have in the modules and wires paradigm used for the G2. Just as it seems odd to have to implement control algoritms with analog modules.
It seems to me that the best way to go is to stay close to the current visual programming language (the module and wire concept) and to try to come up with modules that can extend the language more towards a general purpose programming language instead of strictly emulating an analog synthesizer.
To reach such a goal one would have to come up with modules that are suitable to implement control structures.
When I was taught programming several years ago visual programming was just a potentially interesting way to program computers, an oddity. It never became clear to me then how one could visually build a program that would be easy to read - visual inspection of a program should give a clue as to what the program does, or at least what it tries to do. This is a property the current G2 language does not really posess - and that might be the real problem.
The state machine is just an example of a simple control module, and I'm not really sure it is the right way to go (but I'm not smart enough to come up with a real solution).
Let me write a few words about the state machine nevertheless.
Over the years I've had several tries for building a generalized state machine, but I almost always ended up not using that code anymore as it is often in a general purpose programming language more convenient to program it on the fly using a state variable and a nested case statement that differentiates on the current state and the current event(s) that come(s) in. In a visual enveronment this is not really an available escape though, case statements end up looking like demultiplexers, sample and holds etc where it's immediately unclear again what the purpose of the construct is.
All constructions I tried specified the state machines as tables, like
(state1, event1, state2, action1)
(state1, event2, state3, action2)
etc.
Also I used a more complex model in which actions could as well be tied to events directly disregarding the current state - this can save quite some lines of spefications. This system served me well on small embedded systems for several years, but later I built a Forth compiler for such systems and I now use a Forth / assembly mix exclusively.
For the G2 I can see a module having some event inputs, some action outputs (maybe a blue state output) and a table to specify it's behaviour.
But I think just saying "state machine" will not solve the problems we have. At best it can be a step towards a slolution.
Jan. |
|
|
Back to top
|
|
|
jksuperstar
Joined: Aug 20, 2004
Posts: 2503
Location: Denver
Audio files: 1
G2 patch files: 18
|
| Posted: Mon Mar 28, 2005 9:35 am Post subject:
|
|
|
| I agree, a look-up table is most likely the most efficient (and flexible) approach to either state-machine desgin, or random math function simplification. Even an 8-bit (256 location) table (with possible interpolation) could be used for anything from wavetable synthesis to state machines, sequencers, division, and other more complex math functions. If there was 1 module that could be added to the G2, this would be my vote! Of course, it gets more complex (for Clavia to implement) when you consider where this table sits in memory, how it is involved with the patch file, and whether or not variations are allowed (meaning 8*256, or 2K worth of table info must be stored with the patch for EACH table). But, all those things are trade offs, and the power of an addressable look-up table should be strongly impressed upon the Clavia designers. |
|
|
Back to top
|
|
|
Acidfever
Joined: Aug 25, 2004
Posts: 49
|
| Posted: Tue Mar 29, 2005 7:29 am Post subject:
|
|
|
I do see the possibilities in this feature but i am not convinced this should be implemented soon.
Why?
I will explain. As somebody in a earlier post mentioned his opinion was that the only advantage Clavia has over sollutions like Csound is the interface. And it is here that i have to disagree.
I have been working with reaktor for quite some time before i bought my G2 Engine. The reason i bought it is because i liked the sound, but also the fact that it was less hard to build own patches. With reaktor i spend hours or even days on making a patch and not making music. With the G2 i spend some time making a patch but not nearly as long as i would on Reaktor. This combined with the stable and trustworthy dedicated hardware environment is the real strenght of the Clavia modulars. If you combine this with the interface the G2 keyboard users get this is even better.
If you want complex possibilities and experimental options you can do a lot on the G2 allready. I would however have no problems with this module apearing since it could indeed allow for very interesting patches.
What i want to say is: If you make music, simplicity and stability is more important than complex features in a lot of occasions. These features make the G2 more powerfull, but not necessarily more usable.
Just my 2 cents....... |
|
|
Back to top
|
|
|
mosc
Site Admin
Joined: Jan 31, 2003
Posts: 18235
Location: Durham, NC
Audio files: 222
G2 patch files: 60
|
| Posted: Tue Mar 29, 2005 8:12 am Post subject:
|
|
|
All this talk about scripting is OK, but I'd vote to keep Clavia working on developing much needed more conventional modules, like a fixed filter bank and a binary up/down counter with asynchronous presets. The first is essential for analog synthesis and the second would really fix a big hole in the G2's sequencer capabilities. There are other modules that are needed before a scripting module.
Scripting would be used by only a few people; most musicians aren't interested in developing and debugging code. For those that are interested in scripting the choice of language style would be pretty important. We all have our likes and dislikes about scripting. Some people think a Lisp-like language is great - I personally wouldn't even consider using Lisp. I once worked on an AI project using the language. I detest it. I love AWK-like languages, but some may dislike these. Forth is cool, but not everyone is going to dig it.
Programming is something best kept outside of the G2, IMHO. There are many excellent programming environments that one can use with the G2 via MIDI. Keykit, MAX, PD, SC, etc. There are many outstanding choices and styles of programming environments. I guess there is a lot to gripe about MIDI, but it's still a great tool. It's very usable.
To summarize, the G2 is a modern version of the analog modular synthesizer. Improvements sould be made consistent with that vision. I look at my Moog Modular as I type this post and there is a big fixed filter bank. The lack of one on the G2 is very apparent in contrast. I would hope Clavia would keep focused.
_________________
--Howard
my music and other stuff |
|
|
Back to top
|
|
|
cebec
Joined: Apr 19, 2004
Posts: 1098
Location: Virginia
Audio files: 3
G2 patch files: 31
|
| Posted: Tue Mar 29, 2005 8:51 am Post subject:
|
|
|
| i'd probably not find much use in a scripting module at first... i'd definitely be more interested in the modules Howard's suggesting as well as some of the math modules many have been throwing out there. |
|
|
Back to top
|
|
|
|
Forum index » Clavia Nord Modular » Wish List
FAQ
Calendar
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Chat Room
