On 26 Apr 2009, at 04:38, Robert Poor wrote:
do you get another generator, or is the already sounding generator of the key reset?
The answer is "yes" -- it behaves one of those two ways. :) But it's a trivial change -- about four lines of code -- to make it behave the other way.
These are different musical effects, I think. I want to have one generator per key. I think of keeping it when doing transpositions. I also spawn one thread for each key - at the release. Then fundamental problem is that Chuck cannot schedule and re-schedule events in the future; this must be done by creating a new thread.
I don't want to presume your proficiency in coding, but I wrote this as an example for people to look at and adapt as appropriate.
The code was too massive too extract just the things I wanted to know, though examples are nice. (Note that in ISO/ANSI C/C++, names starting with '_' are reserved for the implementation of the compiler, though Chuck is a different language.) Also, the idea of keeping threads alive in order prevent memory leaks seems an unwanted workaround, though perhaps it may be necessary if not possible to do it otherwise. As for killing threads, when dialing a phone number, already one and a half decade ago, the computer could create thousands of threads, each one doing a search path. When one is found and reporting back, it would be a waste of resources letting the others hanging around. So I think killing threads would be normal programming.
Let me know off-list if you want more help.
On the lists I know (for example the Bison lists), most everything are kept on-list. Hans