[CM] Fwd: Linux/Midi Test
taube at uiuc.edu
Tue Aug 11 05:22:21 PDT 2009
you might try adding that line to sendMessageNow() in cm/src/
juce_Amalgamated.cpp then remake grace and test your example again
(audio on my linux emulator doesnt work at all so i cant test it
On Aug 11, 2009, at 6:57 AM, lieven moors wrote:
> I think I might know what the problem is with Juce. I had a look at
> Juce code myself,
> and it looks like sendMessageNow() is not calling the
> this is an excerpt from the ALSA API documentation:
> If the event is sent immediately without enqueued, the sender
> doesn't take care of queue and timestamp. As well as the case above,
> there is a function to set the direct delivery,
> The program can be more simplified as follows:
> void direct_delivery(snd_seq_t <http://www.alsa-project.org/alsa-doc/alsa-lib/group___sequencer.html#g527eff2e3b3c7dd45cac6fdd2ceee964
> > *seq)
> snd_seq_event_t <http://www.alsa-project.org/alsa-doc/alsa-lib/structsnd__seq__event.html
> > ev;
> snd_seq_ev_clear <http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_middle.html#g6ed1a615ac4c8f02832198ab04fa8f55
> snd_seq_ev_set_source <http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_middle.html#gabdd5b232c8f306b4ced5eb7edf12844
> >(&ev, port);
> snd_seq_ev_set_subs <http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_middle.html#gd61b73ca763e011b23df35dc746ad760
> snd_seq_ev_set_direct <http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_middle.html#gdda452e0b4ea3b5f722795d015159388
> ... // set event type, data, so on..
> snd_seq_event_output <http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_event.html#g8b955646b0cc007f6435f9ab8f1b7228
> >(seq, &ev);
> snd_seq_drain_output <http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_event.html#g841a0cc485b82fd0b80c92274dfe36c0
> You should flush event soon after output event. Otherwise, the
> is enqueued on output queue of ALSA library (not in the kernel!), and
> will be never processed until this queue becomes full.
> I sounds like this might be excactly what happens....
> I wonder what you or Andrew think about this, because I'm not too sure
> about it.
> It seems almost too simple to be true.
> Heinrich Taube wrote:
>> andrew thank you soooo much for your effort. maybe i could post your
>> code to the juce linux group to see if they have any ideas?
>> Begin forwarded message:
>>> From: William Andrew Burnson <burnson2 at illinois.edu>
>>> Date: August 10, 2009 10:04:20 PM CDT
>>> To: taube at illinois.edu
>>> Subject: Linux/Midi Test
>>> I wrote a simple JUCE console program to just spit out midi messages
>>> to Timidity in a single thread. I got the same results as we saw
>>> earlier today. I didn't even put the thread to sleep--I just had it
>>> spin through the hi-res timer until the right time and then used
>>> sendMessageNow to fire the MIDI messages. It was just as jerky.
>>> This means there is nothing you can do about this without going to a
>>> deeper level such as writing your own interface to ALSA. Whatever
>>> JUCE is doing doesn't seem to be sufficient for any kind of time
>>> I suppose there are two types of uses of MIDI:
>>> MIDI -> Soundfont -> Audio
>>> In this case, there should be no reason why somewhere you couldn't
>>> specify "future" midi messages into the ALSA/Timidity bridge and it
>>> would render them precisely where they needed to be in terms of
>>> sampled audio.
>>> MIDI -> External device
>>> In this case, you would want access to a SMTPE clock.
>>> I am not sure if the kernel will make a difference. In any case, we
>>> could try my test program on different kernels to see, but I'm
>>> guessing it's a JUCE issue.
> Cmdist mailing list
> Cmdist at ccrma.stanford.edu
More information about the Cmdist