[chuck-users] semi complicated midi setup

[Adam Tindale]

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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users