Hi I'd like to control chuck from my 3 usb keyboards. Preferably with the abiliy to split one or more of the keyboards to different sounds, dynamic voice allocation is a must for polyphonic sound. I'd like to make the code as modular as possible, in order to easily create one such setup for each song. This means that the definition of which keyboard(s) is spilt and how + routing to actual instruments + code for each instrument should be in seperate files. I'm still very new to chuck, so my first question is simply: is this at all possible with chuck? The second question: (if possible) could soneone provide a rough outline, how to achieve what I'd like? Thanks in advance for any pointers... -- peace, love & harmony Atte http://www.atte.dk
On 18-Nov-05, at 10:53 AM, Atte André Jensen wrote:
I'd like to control chuck from my 3 usb keyboards. Preferably with the abiliy to split one or more of the keyboards to different sounds, dynamic voice allocation is a must for polyphonic sound.
I'd like to make the code as modular as possible, in order to easily create one such setup for each song. This means that the definition of which keyboard(s) is spilt and how + routing to actual instruments + code for each instrument should be in seperate files.
I'm still very new to chuck, so my first question is simply: is this at all possible with chuck?
Yes. To use chuck with multiple files, include them all on the command line. ie $ chuck foo.ck bar.ck
The second question: (if possible) could soneone provide a rough outline, how to achieve what I'd like?
The beauty of a language like chuck is that you can solve any problem
in many different ways. I don't think this is the best solution, but
it's the easiest to explain:
1) get MIDI information from keyboard. This is covered in the manual.
2) Look at the midi info;
if ((notein>x)&&(notein
Graham Percival wrote:
That should be enough to get you started.
Thanks, I'll look at it as soon as possible. Looks promissing! -- peace, love & harmony Atte http://www.atte.dk
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? -- peace, love & harmony Atte http://www.atte.dk
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
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
participants (3)
-
Adam Tindale -
Atte André Jensen -
Graham Percival