[CM] Fwd: Linux/Midi Test

[Heinrich Taube]

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  
myself today)

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  
> the
> Juce code myself,
> and it looks like sendMessageNow() is not calling the
> snd_seq_drain_output().
> 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,
> snd_seq_ev_set_direct()
> <http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_middle.html#gdda452e0b4ea3b5f722795d015159388 
> >.
> 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 
> >(&ev);
>        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 
> >(&ev);
>        snd_seq_ev_set_direct <http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_middle.html#gdda452e0b4ea3b5f722795d015159388 
> >(&ev);
>        ... // 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 
> >(seq);
> 	}
>
>    You should flush event soon after output event. Otherwise, the  
> event
> 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
>>> precision.
>>>
>>> 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
> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist