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.

On 11 June 2010 13:34, Thomas Girod <girodt@gmail.com> wrote:

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