Hi Victor, I've been thinking a little more about how to implement opcode arrays; the following is a bit of random thoughts on it: I think the tricky part is hooking up the argument and output pointers. I imagine the opcode array itself would be an opcode, something like: out1, ... oparray array_var_name, xindex, arg1, arg2, ... The user wouldn't use the above, they would the myOpArray[1] syntax, but it would get compiled down to the above (the array name would be transformed to the first arg to oparray, he index in the [] would get transformed to the second arg to oparray). the initialization function may need to have the opcode type: myoparray[] oparrayinit vco2[10] the intiailization of the opcode itself couldn't happen in the oparrayinit, as there's no arguments being given and you can't really give any as they can differ from opcode to opcod in the array. So the initialization of the opcodes in the oparray would happen when the oparray opcode has its initialization function run, and basically it will initialize each opcode within its array with the same arg pointers that were given to the oparray opcode. The parser could check the signature of the opcode type of the oparray to check if the values being give to the oparray opcode match those of the opcode type it holds. So, something like this: ipch = 440 myoparray[] oparrayinit vco2[10] aout init 0 for i = 0, i < 10, i = i +1 aout1 myoparray[i] 5000, ipch * (i + 1) aout = aout + aout1 fend would compile down in csound to: ipch = 440 myoparray[] oparrayinit vco2[10] aout init 0 __alabel: i = 0 _i1 = ipch * (i + 1) aout1 oparray myoparray, i, 500, _i1 aout = aout + aout1 i = i + 1 if i < 10 goto __alabel something like that (the expressions above would be opcodes really). oparray could use auxch to allocate memory for the structs of the opcode, as long as the parser checked the types of args that went into oparray match those as the type that go into the opcode it is an array of, i think this could work to make sure the pointers are set up correctly. One thing to think about is that Csound compiles down everything into a group of structs, but when it does that, it optimizes at that point and links everything very tightly with pointers. I was thinking about this the other day and realized that this makes it *much* harder to dynamically allocate and remove opcodes at runtime; the thought to change how Csound is linked together has crossed my mind as a possible necessary change to make the above aspect possible, at the expense of more memory usage (though really, it'd be fairly minimal, far less than even loading a small audio file into memory). So... I think the oparray might actually be implementable within the current Csound engine, just would need a parser addition to set things up. I'm currently attending the Warsaw Autumn Festival and will be going to either one or two concerts a day for this entire week, so have slowed down in all of my work across the board at the moment. I'd like to get further along with the parser implementing currently existing features, but I think it'd be great to get into implementing this once that is done. I agree that recursion isn't so great, as it automatically requires a seperate UDO for your instrument, which decreases the portability of the instrument. (Though, I started to wonder about inner UDO's, like inner classes in Java, where UDO could be defned within an instrument and only used within that instrument; could avoid nameclashes that way, but not sure how often it'd be used). steven On 9/24/06, Victor Lazzarini wrote: > I understand. It might be worthwhile looking at > the problem, whenever there is time. I was thinking > that the mechanism for recursive opcodes could be > adapted for opcode arrays. > > In fact, recursive opcodes are great for doing the > bank of opcodes thing, resulting in very compact > code. I love it. However, it is not easiest of the > codes to read and understand. I am also not so sure > about performance penalties. > > Dynamic allocation of opcodes and instruments is > also something very desirable, is it not? > > Victor > > > > > Hi Victor, > > > > Arrays of opcodes seem tricky as the opcodes need to be > > allocated at run-time versus being compiled down as the > > array intiailization is a variable. I don't think there > > is currently any dynamic opcode allocation within the > > engine, so that would have be added there, as well as in > > the language. > > > > Though, it is possible to do variable amount of opcodes > > already using recursive UDO's, though the mechanism for > > that is different that allocating opcodes at runtime. > > > > steven > > > > > > On 9/22/06, Victor Lazzarini > > > wrote: I think definitely we should look into adding > > > loops, as well as variable/opcode arrays. I am > > > thinking on the lines of the following syntax: > > > > > > a1[] arrayinit 10 > > > > > > for ki=0, ki < 10, ki = ki + 1 > > > a1[ki] oscil 10000, kfun*ki, 1 > > > endfor > > > > > > Of course this is just an example, perhaps we will > > > need to call a-, k-, i-variable arrays something else > > > (va, vk, vi ?). > > > > > > This would also mean that 10 separate oscillators would > > > be created, and the outputs are stored in a1[0]-a1[9]. > > > > > > Now this is not only syntatic sugar, but a major > > > addition to the language. Not sure how it would > > > implemented, but it would be very nice. > > > > > > > Hi All, > > > > > > > > Just another update with the new parser. I've now > > > > gotten to the point of getting labels and goto's > > > > working. From here on my list I have: > > > > > > > > -if-goto > > > > -if-then-elseif-else > > > > -UDO's > > > > -functions > > > > -polymorphic opcodes (need to check if this isn't > > > > done) -macros > > > > -memory clean up > > > > -cleaning up grammar > > > > -error reporting > > > > -general cleaning up of files > > > > > > > > I am mostly going in the above order and am continuing > > > > to work by creating a test first then working to make > > > > the test work. > > > > > > > > Also, I thought CsoundAV had some sort of while loop > > > > construct using: > > > > > > > > while (bool expression) > > > > .. opcode statements .. > > > > wend > > > > > > > > but I could not find anything like this in the > > > > documentation (maybe it was just a suggested idea on > > > > the mailing list a long time ago). The question I'm > > > > wondering is should while loops and for loops be added > > > > to Csound? It's all syntactic sugar, but it's > > > > convenient. (For-loops would need a different > > > > delimiter though between statements as semicolons are > > > comments). > > > > > steven > > > > > > > > > > > > > > ---------------------------------------------------------- > > > > --------------- Take Surveys. Earn Cash. Influence the > > > > Future of IT Join SourceForge.net's Techsay panel and > > > > you'll get the chance to share your opinions on IT & > > > business topics through brief surveys -- and earn cash > > > > > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > > _______________________________________________ > > > > Csound-devel mailing list > > > > Csound-devel@lists.sourceforge.net > > > > > > https://lists.sourceforge.net/lists/listinfo/csound-devel > > > > > > ---------------------------------------------------------- > > > --------------- Take Surveys. Earn Cash. Influence the > > > Future of IT Join SourceForge.net's Techsay panel and > > > you'll get the chance to share your opinions on IT & > > > business topics through brief surveys -- and earn cash > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > _______________________________________________ > > > Csound-devel mailing list > > > Csound-devel@lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/csound-devel > > > > > > > ---------------------------------------------------------- > > --------------- Take Surveys. Earn Cash. Influence the > > Future of IT Join SourceForge.net's Techsay panel and > > you'll get the chance to share your opinions on IT & > > business topics through brief surveys -- and earn cash > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > Csound-devel mailing list > > Csound-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/csound-devel > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net