Hi, I have a system for doing what you propose to do, but I don't know if it will work for you. I have a drum controller that spits out midi that I route to different performance patches. I have a variety of chuck files that I use for this. drums.ck is a patch that has a class drum. The drum class has a bunch of static events and static data (velocities). mapping.ck is a patch that takes the midi input from the controller and sets the static data in drum and then broadcasts events tune1.ck tune2.ck etc these patches all have shreds that listen for events in the drum class and then trigger an action. I also have a couple of synth and sampler classes that behave the way I like that I can use in the tunes. When I play live I will load all of my synth classes and drums.ck and mapping.ck and then chuck and unchuck each tune as we get to them. This is one suggestion but my implementation will be much different since I am using a drum controller and I only have 10 things to play, unlike having 3 keyboards. This is the way I do things now. I have been using ChucK for a long time and I think that Graham made an excellent suggestion by designing for a long time and then implement. Do a lot of research into the language and figure out how to pass messages between shreds and use the class system. You may want to start with one patch that does everything and then as you get more involved you can start to rip modules out and store them in different files. That is how I built my system. It took months of building and rebuilding. Good luck. --art On 22-Nov-05, at 3:14 PM, Graham Percival wrote:
On 22-Nov-05, at 1:39 PM, Atte André Jensen wrote:
Graham Percival wrote:
I don't think this is the best solution,
I'm also interrested in the best solution. Could you give a few pointers?
No. :) I mean that literally -- I don't think I _can_ give you a best solution; it's not that I'm not willing to do so.
It comes down to exactly what you're trying to do (and I don't know that), how you like to structure programs, etc. You could probably do this with classes -- make a HandleKeyboard class, then instantiate one of those for each keyboard.
I think the best way to find the best solution is to go ahead and get it working, using whatever method(s) you can. Use that to learn about chuck, figure out exactly what you want to do, etc. Once that's all working, ignore your current program(s) and start again from scratch. Spend a week just thinking about the general design before programming anything.
Of course, I've only taken one course on software engineering in my life, and that was in 1998. Nor have I done any programming since then, up until a few months ago. So I don't claim to be an expert. :) But that's how I would go about this.
IMHO, the biggest problem is in deciding exactly what you want. Once you've done that, the actual design and programming is pretty easy.
Good luck, - Graham _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users