Hi Thomas!
What I use for this kind of case (my Akai LPD8, for example) is a class with
it's own sporked listener shred.
At instantiation it could try to open all MIDI devices in turn, until the
name of the device is whatever the name of your controller is. from there on
you can add members and member functions that reflect whatever you want to
do with the device, including a public event that other shreds could wait
for. In the case of controllers with leds you'd probably also have
member-functions that your code could use to set these, with your class
handling the MIDI.
If you build something like that once it will save you a lot of time in the
long run and only having to do MIDI (with all of its magic numbers) once
should make your coding a lot more pleasant. The class could sit in its own
file (if you make it public), or you could simply copy and paste it to the
bottom of your current project.
Hope that helps?
Kas.
On 11 June 2010 13:34, Thomas Girod
Hi there.
I'm currently working on a chuck project that is progressively increasing in size. Some parts of this project are already quite generic, and I will probably use them in other projects later (namely, an interface to communicate with the novation's monome ripoff).
So I start to wonder: how can I organize my code for easy reuse ? What are the options / good practices to write less monolithic chuck code ? Is it possible to write something that could behave as a library ?
Thanks for your attention
Tom
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users