[chuck-users] semi complicated midi setup
adamtindale at hotmail.com
Tue Nov 22 23:20:48 EST 2005
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.
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
> 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
> Good luck,
> - Graham
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
More information about the chuck-users