[chuck-users] sending midi program change

[Kassen]

Bruce;


I generally use it out of habit and then very occasionally get surprised
> when it doesn't work. Fortunately, practically all languages thes days
> are written by people with C backgrounds, so this is included by
> default. Octal parsing is more intermittent :)


It's usefull to have but I don't think I saw it in ChucK before. Learned
another thing.


> Ah yes, so the underlying functions send an arbitrary length vector, but
> the polymorphic functions actually exposed to ChucK take the midi
> message and stuff all three bytes directly into the message without
> checking. This is where it would be nice to have something that knew
> what message was what.


Yes, I agree.



>
> My favoured solution [1] would be to have the midi message sending
> function know exactly how long the different types of messages should be
> and automatically send just that number of bytes from the message thing,
> unless overridden by a specific parameter.


A while ago I proposed to Ge to turn the MIDI implementation in ChucK into
something like was done with the HID and adress them like functions. On the
HID side isButtonDown() and so on make everything much easier to deal with
then the old way of refering to each type of incoming data by a number. The
exact same could be done quite easily with MIDI and at the same time
message-length could be dealt with. Dealing with the numbers is very
educational and it works but it's no fun at all and I don't think anybody
feels like remembering 192 means a program change.

I think Ge put this proposal on the list.

In the meantime; I noticed that your own code that solves most of the
numbers game isn't linked to on the Wiki. I think it would be quite
valuable. Should I link to it there? Would you like to do this yourself?

More interestingly, perhaps, the midi functions have polymorphic
> versions which take a number of bytes (1,2 or 3) and just send those. That
> would provide an immediate solution to make my own midi library work
> properly.
>
> So, what do people think about that change to MidiOut::send() in
> midiio_rtmidi.c ? Unless I hear some loud screaming, I'll write and
> submit the patch tonight.


I think it would be great but it might be best to check with Ge to avoid
paralel efforts, considdering something similar is on the todo list.


Another question, if we are talking about this anyway, is the MidiIn. I
think the MidiIn might have some sort of filter that only makes it react to
three byte messages, at least I think I got some quite odd result when
feeding it other stuff. This isn't bad as such; we probably want to be able
to avoid having every clock tick trigger some potentially complicated
parsing sequence but maybe those filter settings should be configurable as a
property of the MidiIn object?

Thinking out loud again...

Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20070105/34d21aba/attachment.htm