Is there any reason why the timing of MIDI messages sent out via portmidi to
a Firewire 410 in a Win7 system using Csound 6.01 should be unstable?

Csound's own timing is rock-solid, that's obvious. The reason this question
arises is because I'm testing a Vermona MIDI interface module in my new
euro-rack modular system, and by the time the Vermona processes the MIDI
data and converts note-ons and note-offs to gates, there is some very
audible time slop.

The reason I want to rule out portmidi as the source of errors is because
the timing slop is absolutely uniform from one test run to the next. This
probably means that the Vermona module is using a too-slow chip, but before
I contact them I'd like to know whether anyone in the Csound community has
had experience with timing instability on MIDI output.



--
View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Output-Timing-tp5730695.html
Sent from the Csound - General mailing list archive at Nabble.com.

Tentatively, I'm going to have to say, yeah, it's a system-level Csound
problem. When I set up the identical scenario in Reason, transmitting a
regular stream of notes to the Vermona module via the same MIDI output from
the computer, the timing is rock-solid.

It appears that somehow Csound's portmidi implementation (or possibly the
midiout opcode) is packed with jitter. Have others reported this?



--
View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Output-Timing-tp5730695p5730696.html
Sent from the Csound - General mailing list archive at Nabble.com.

> MIDI jitter in Csound is determined by ksmps, all MIDI messsages are sent
at
> block boundaries. reducing ksmps should fix you issue.

That's a reasonable hypothesis, Andrés -- but ksmps was already set to 1, so
I'm pretty sure we need to dig deeper to find the cause.

Just now I tried reducing the number of threads to 1. I also tried reducing
-b and -B to low settings, just to check. These changes seem to make some
small, marginal improvements in the MIDI output timing, but the timing
problem is still there.

Also, for the record, I'm pretty sure that Reason's control rate is lower
than its sampling rate -- so if the problem were as you describe, we would
have to conclude that Propellerhead has found a way of resolving the issue
without setting their control rate to the audio rate.

At a guess (I can document this if you like and get actual numbers) the
instabilities I'm hearing are at least +/- 20ms. At an audio rate of
44.1kHz, there would be 44 samples in one millisecond, so on your
hypothesis, a discrepancy of 20ms would require a ksmps setting of at least
800. I doubt anybody runs Csound with such a high setting.

--JA



--
View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Output-Timing-tp5730695p5730700.html
Sent from the Csound - General mailing list archive at Nabble.com.

MIDI output timing in Csound is not great, as the system was never designed with a MIDI out in mind,
and MIDI output was hacked into the software sometime in the early 2000s. The portmidi module written
for Csound 5 does not improve on this. I am not sure whether the alsa raw midi or alsa sequencer
modules are much better (linux only).

As far as I understand it, we would need to overhaul it completely, from the ground up to achieve a 
good result. Since it has never been a  priority, we have not looked into it too closely.

Note that MIDI input does not suffer from the same issues, and has a good response (depending 
directly on ksmps).

So the lowdown is: yes, the timing is not good, this is a known issue, and we do not have
any immediate plans to resolve it (but this may change).

Victor
On 10 Dec 2013, at 21:25, Jim Aikin wrote:

>> MIDI jitter in Csound is determined by ksmps, all MIDI messsages are sent
> at
>> block boundaries. reducing ksmps should fix you issue.
> 
> That's a reasonable hypothesis, Andrés -- but ksmps was already set to 1, so
> I'm pretty sure we need to dig deeper to find the cause.
> 
> Just now I tried reducing the number of threads to 1. I also tried reducing
> -b and -B to low settings, just to check. These changes seem to make some
> small, marginal improvements in the MIDI output timing, but the timing
> problem is still there.
> 
> Also, for the record, I'm pretty sure that Reason's control rate is lower
> than its sampling rate -- so if the problem were as you describe, we would
> have to conclude that Propellerhead has found a way of resolving the issue
> without setting their control rate to the audio rate.
> 
> At a guess (I can document this if you like and get actual numbers) the
> instabilities I'm hearing are at least +/- 20ms. At an audio rate of
> 44.1kHz, there would be 44 samples in one millisecond, so on your
> hypothesis, a discrepancy of 20ms would require a ksmps setting of at least
> 800. I doubt anybody runs Csound with such a high setting.
> 
> --JA
> 
> 
> 
> --
> View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Output-Timing-tp5730695p5730700.html
> Sent from the Csound - General mailing list archive at Nabble.com.
> 
> 
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>            https://sourceforge.net/p/csound/tickets/
> csound5:
>            https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie

To elaborate on this a little more: the major issue here is that Csound's midi out opcodes will send out
a message immediately at the time they are run by invoking the midi out callback directly, 
without any timestamping method. So depending on the computation load before or after the opcode call, 
the message might be sent with various degrees of jitter.

The correct way of doing this is to tie in the midi callback to a timer and make
the opcodes add messages to a timestamped list that is processed at regular intervals. We could also use the
audio stream timestamps, but I think that would potentially be more complicated (due to the different audio 
backends used by Csound).

Victor

On 10 Dec 2013, at 23:27, Victor Lazzarini wrote:

> MIDI output timing in Csound is not great, as the system was never designed with a MIDI out in mind,
> and MIDI output was hacked into the software sometime in the early 2000s. The portmidi module written
> for Csound 5 does not improve on this. I am not sure whether the alsa raw midi or alsa sequencer
> modules are much better (linux only).
> 
> As far as I understand it, we would need to overhaul it completely, from the ground up to achieve a 
> good result. Since it has never been a  priority, we have not looked into it too closely.
> 
> Note that MIDI input does not suffer from the same issues, and has a good response (depending 
> directly on ksmps).
> 
> So the lowdown is: yes, the timing is not good, this is a known issue, and we do not have
> any immediate plans to resolve it (but this may change).
> 
> Victor
> On 10 Dec 2013, at 21:25, Jim Aikin wrote:
> 
>>> MIDI jitter in Csound is determined by ksmps, all MIDI messsages are sent
>> at
>>> block boundaries. reducing ksmps should fix you issue.
>> 
>> That's a reasonable hypothesis, Andrés -- but ksmps was already set to 1, so
>> I'm pretty sure we need to dig deeper to find the cause.
>> 
>> Just now I tried reducing the number of threads to 1. I also tried reducing
>> -b and -B to low settings, just to check. These changes seem to make some
>> small, marginal improvements in the MIDI output timing, but the timing
>> problem is still there.
>> 
>> Also, for the record, I'm pretty sure that Reason's control rate is lower
>> than its sampling rate -- so if the problem were as you describe, we would
>> have to conclude that Propellerhead has found a way of resolving the issue
>> without setting their control rate to the audio rate.
>> 
>> At a guess (I can document this if you like and get actual numbers) the
>> instabilities I'm hearing are at least +/- 20ms. At an audio rate of
>> 44.1kHz, there would be 44 samples in one millisecond, so on your
>> hypothesis, a discrepancy of 20ms would require a ksmps setting of at least
>> 800. I doubt anybody runs Csound with such a high setting.
>> 
>> --JA
>> 
>> 
>> 
>> --
>> View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Output-Timing-tp5730695p5730700.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>> 
>> 
>> Send bugs reports to the Sourceforge bug trackers
>> csound6:
>>           https://sourceforge.net/p/csound/tickets/
>> csound5:
>>           https://sourceforge.net/p/csound/bugs/
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>> 
>> 
> 
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
> 
> 
> 
> 
> 
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>            https://sourceforge.net/p/csound/tickets/
> csound5:
>            https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie

> MIDI output timing in Csound is not great, as the system was never designed
> with a MIDI out in mind, and MIDI output was hacked into the software
> sometime
> in the early 2000s.

Thanks for the clarification, Victor. I would tend to agree that it's
probably not a high priority, as there are certainly many other ways to send
MIDI messages. (Starting with Pd, I suppose. I may need to look into that.)

Today we have many technologies and methods to choose from. At the moment
I'm exploring a few options to learn what works best with a hardware modular
synth. Unfortunately, nobody is building a module that can receive OSC
messages and translate them into voltages, so MIDI was my next choice.



--
View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Output-Timing-tp5730695p5730705.html
Sent from the Csound - General mailing list archive at Nabble.com.

Unfortunately, nobody is building a module that can receive OSC
messages and translate them into voltages, so MIDI was my next choice.

Poking around on the Web, looking for OSC-to-CV converters, I found this
YouTube video:

https://www.youtube.com/watch?v=pOeAzgHrPTk

It appears to be only a prototype, however, using a piece of hardware called
mbed. I don't see any indication that the device shown in the video is being
marketed.

If I were going to use MIDI to connect a computer to something like the
Moogerfoogers, I think I'd be tempted to use Pd rather than Csound. I don't
really care for the Pd graphic UI, but in its original incarnation Pd was
created as a MIDI processor, so it's a reasonable guess that the current
MIDI functionality still has decent timing.



--
View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Output-Timing-tp5730695p5730710.html
Sent from the Csound - General mailing list archive at Nabble.com.

Poking around on the Web, looking for OSC-to-CV converters, I found this
YouTube video:

mbed OSC to CV Converter

It appears to be only a prototype, however, using a piece of hardware called
mbed. I don't see any indication that the device shown in the video is being
marketed.

If I were going to use MIDI to connect a computer to something like the
Moogerfoogers, I think I'd be tempted to use Pd rather than Csound. I don't
really care for the Pd graphic UI, but in its original incarnation Pd was
created as a MIDI processor, so it's a reasonable guess that the current
MIDI functionality still has decent timing.



--
View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Output-Timing-tp5730695p5730710.html
Sent from the Csound - General mailing list archive at Nabble.com.


Send bugs reports to the Sourceforge bug trackers
csound6:
            https://sourceforge.net/p/csound/tickets/
csound5:
            https://sourceforge.net/p/csound/bugs/
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Pd still outputs MIDI at control rate (usually the sample block size of 
64). I've tested it to be accurate on average but any individual event 
is quantized to occur at the block boundary.
With OSC in Pd the messages will still go out at k-rate. I guess in 
csound if ksamps is 1 then OSC timing should be the most accurate.
I was thinking of making an OSCtoCV converter using a Rabbit RCM3700 and 
some 16-bit DACs.

Martin

On 2013-12-11 00:59, Jim Aikin wrote:
> Poking around on the Web, looking for OSC-to-CV converters, I found this
> YouTube video:
>
> https://www.youtube.com/watch?v=pOeAzgHrPTk
>
> It appears to be only a prototype, however, using a piece of hardware called
> mbed. I don't see any indication that the device shown in the video is being
> marketed.
>
> If I were going to use MIDI to connect a computer to something like the
> Moogerfoogers, I think I'd be tempted to use Pd rather than Csound. I don't
> really care for the Pd graphic UI, but in its original incarnation Pd was
> created as a MIDI processor, so it's a reasonable guess that the current
> MIDI functionality still has decent timing.
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Output-Timing-tp5730695p5730710.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>              https://sourceforge.net/p/csound/tickets/
> csound5:
>              https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>
>

> I was thinking of making an OSCtoCV converter using a Rabbit RCM3700 and
> some 16-bit DACs.

If you're serious about doing this, send me an email
(midiguru23@sbcglobal.net), as I have a couple of half-baked ideas about how
it could be set up. Also, FYI, Expert Sleepers uses 24-bit DACs in their
synth modules. Given how finicky analog synth users are about their audio,
this might be worth considering.

The MOTU audio interfaces work with analog synths because they're
DC-coupled. You can send one an "audio" signal at .01Hz with a big DC
offset, and it will happily crank out a positive voltage all day long. Or at
least, that's the theory -- I haven't tested any of this stuff yet. There
are other things about this scheme that I haven't yet investigated. If the
outputs are at line level, they would still have to be boosted significantly
in order to work in an analog modular synth. In addition, you'll most likely
have a snake of cables running from the MOTU interface over to the modular
synth, which is perhaps not ideal in a small studio.

The least expensive MOTU interface with this capability retails for $549. A
slightly less expensive alternative, at the interface side, is the PreSonus
1818VSL (retail $499), which has an ADAT lightpipe output. This should
connect neatly to the Expert Sleepers ES-3 synth module, which outputs
synth-level signals.

Either the MOTU or the PreSonus should work (again, in theory -- untested)
with Csound, because Csound doesn't care if it's transmitting audio with a
DC offset. You would just select the audio channel as the instr output and
then send it the a-rate signal of your choosing.

At that point, Csound could act as the intermediary in a hybrid system. It
could receive OSC messages from, for example, touchOSC on an iPad, translate
them into audio, and send them on to the modular synth. I'd love to try
this, but it would be a wee bit expensive to set up and test, when it might
not work....



--
View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Output-Timing-tp5730695p5730728.html
Sent from the Csound - General mailing list archive at Nabble.com.

I want to label this exchange in the "Re [Csnd] MIDI Output Timing"
thread as being relevant to how we might use existing or new hardware to
send and receive DC-coupled audio and/or control voltages between Csound
and modular synthesis gear.

There are various MOTU 828 models available on eBay:

  http://www.ebay.com/bhp/motu-828

A 2004 article on the introduction of the 24 bit 96kHz MOTU 828 Mk2,
with a link to an article about the Mk1:

  http://www.soundonsound.com/sos/jul04/articles/motu828mkii.htm

The Mk3 is described here:

  http://www.motu.com/products/motuaudio/828mk3

There are lots of apparently relevant articles:

  https://www.google.com/search?q="MOTU+828"+CV

regarding MOTU's Volta software and Expert Sleepers' Silent Way software.

A list of DC coupled (inputs and outputs I guess) audio interfaces for
use with Silent Way is:

  http://www.expert-sleepers.co.uk/siwacompatibility.html

Their ES-3 Eurorack module receives digital audio data via an ADAT
optical cable and produces 8 channels of CV/audio for modular gear with
an approximately +/1 10 volt range.  Assuming the PCI (inside the
computer) or USB to ADAT optical interface doesn't mess with the
samples, such as for filtering, removing DC offset etc. then these
modules should be fine for controlling Eurorack modular synthesis gear
from Csound.

If the ADAT interface is running at 96kHz, it normally carries 4
channels of audio.  With some Csound programming it should be possible
to get 8 channels of 48kHz through this to a device such as the ES-3.

There is an ES-6 6 input CV to ADAT optical interface, which is clocked
from an ES-3.  The other two inputs are via an ES-7:

  http://www.expert-sleepers.co.uk/es6.html
  http://www.expert-sleepers.co.uk/es7.html

There are other Expert Sleepers hardware modules which I haven't looked
at yet:

  http://www.expert-sleepers.co.uk/hardware.html

 - Robin


On 2013-12-12 7:09 AM, Dominic Melville wrote:

> That's interesting to know. The MOTU 828 etc that work with their own CV
> software, can't remember what it's called, sell very cheap used on eBay
> etc. as far as I know even the V1 828 can do it. 
> 
> I'll be watching this thread with interest. If you do go down the route
> of bashing out ideas for a dedicated converter unit please include me in
> the communication, I can help with the hardware side of it and have a
> few very modular and CV savvy friends. 
> 
> Thanks
> 
> Dominic 
> 
> On Wednesday, December 11, 2013, Jim Aikin wrote:
> 
>> I was thinking of making an OSCtoCV converter using a Rabbit
>> RCM3700 and some 16-bit DACs.
> 
>  If you're serious about doing this, send me an email
>  (midiguru23@sbcglobal.net), as I have a couple of
>  half-baked ideas about how it could be set up. Also, 
>  FYI, Expert Sleepers uses 24-bit DACs in their synth modules.
>  Given how finicky analog synth users are about their audio,
>  this might be worth considering.
>
>  The MOTU audio interfaces work with analog synths because
>  they're DC-coupled. You can send one an "audio" signal at
>  .01Hz with a big DC offset, and it will happily crank out
>  a positive voltage all day long.  Or at least, that's the
>  theory -- I haven't tested any of this stuff yet.
>
>  There are other things about this scheme that I haven't yet
>  investigated.  If the outputs are at line level, they would
>  still have to be boosted significantly in order to work in
>  an analog modular synth.  In addition, you'll most likely
>  have a snake of cables running from the MOTU interface over
>  to the modular synth, which is perhaps not ideal in a small
>  studio.
>
>  The least expensive MOTU interface with this capability
>  retails for $549.  A slightly less expensive alternative, at
>  the interface side, is the PreSonus 1818VSL (retail $499),
>  which has an ADAT lightpipe output.  This should connect
>  neatly to the Expert Sleepers ES-3 synth module, which
>  outputs synth-level signals.
>
>  Either the MOTU or the PreSonus should work (again, in theory
>  -- untested) with Csound, because Csound doesn't care if it's
>  transmitting audio with a DC offset.  You would just select
>  the audio channel as the instr output and then send it the
>  a-rate signal of your choosing.
>
>  At that point, Csound could act as the intermediary in a
>  hybrid system.  It could receive OSC messages from, for example,
>  touchOSC on an iPad, translate them into audio, and send them
>  on to the modular synth.  I'd love to try this, but it would be
>  a wee bit expensive to set up and test, when it might not work....
>
>     View this message in context:
>     http://csound.1045644.n5.nabble.com/MIDI-Output-Timing-tp5730695p5730728.html
>     Sent from the Csound - General mailing list archive at Nabble.com.

I want to label this exchange in the "Re [Csnd] MIDI Output Timing"
thread as being relevant to how we might use existing or new hardware to
send and receive DC-coupled audio and/or control voltages between Csound
and modular synthesis gear.

There are various MOTU 828 models available on eBay:

  http://www.ebay.com/bhp/motu-828

A 2004 article on the introduction of the 24 bit 96kHz MOTU 828 Mk2,
with a link to an article about the Mk1:

  http://www.soundonsound.com/sos/jul04/articles/motu828mkii.htm

The Mk3 is described here:

  http://www.motu.com/products/motuaudio/828mk3

There are lots of apparently relevant articles:

  https://www.google.com/search?q="MOTU+828"+CV

regarding MOTU's Volta software and Expert Sleepers' Silent Way software.

A list of DC coupled (inputs and outputs I guess) audio interfaces for
use with Silent Way is:

  http://www.expert-sleepers.co.uk/siwacompatibility.html

Their ES-3 Eurorack module receives digital audio data via an ADAT
optical cable and produces 8 channels of CV/audio for modular gear with
an approximately +/1 10 volt range.  Assuming the PCI (inside the
computer) or USB to ADAT optical interface doesn't mess with the
samples, such as for filtering, removing DC offset etc. then these
modules should be fine for controlling Eurorack modular synthesis gear
from Csound.

If the ADAT interface is running at 96kHz, it normally carries 4
channels of audio.  With some Csound programming it should be possible
to get 8 channels of 48kHz through this to a device such as the ES-3.

There is an ES-6 6 input CV to ADAT optical interface, which is clocked
from an ES-3.  The other two inputs are via an ES-7:

  http://www.expert-sleepers.co.uk/es6.html
  http://www.expert-sleepers.co.uk/es7.html

There are other Expert Sleepers hardware modules which I haven't looked
at yet:

  http://www.expert-sleepers.co.uk/hardware.html

 - Robin


On 2013-12-12 7:09 AM, Dominic Melville wrote:

> That's interesting to know. The MOTU 828 etc that work with their own CV
> software, can't remember what it's called, sell very cheap used on eBay
> etc. as far as I know even the V1 828 can do it.
>
> I'll be watching this thread with interest. If you do go down the route
> of bashing out ideas for a dedicated converter unit please include me in
> the communication, I can help with the hardware side of it and have a
> few very modular and CV savvy friends.
>
> Thanks
>
> Dominic
>
> On Wednesday, December 11, 2013, Jim Aikin wrote:
>
>> I was thinking of making an OSCtoCV converter using a Rabbit
>> RCM3700 and some 16-bit DACs.
>
>  If you're serious about doing this, send me an email
>  (midiguru23@sbcglobal.net), as I have a couple of
>  half-baked ideas about how it could be set up. Also,
>  FYI, Expert Sleepers uses 24-bit DACs in their synth modules.
>  Given how finicky analog synth users are about their audio,
>  this might be worth considering.
>
>  The MOTU audio interfaces work with analog synths because
>  they're DC-coupled. You can send one an "audio" signal at
>  .01Hz with a big DC offset, and it will happily crank out
>  a positive voltage all day long.  Or at least, that's the
>  theory -- I haven't tested any of this stuff yet.
>
>  There are other things about this scheme that I haven't yet
>  investigated.  If the outputs are at line level, they would
>  still have to be boosted significantly in order to work in
>  an analog modular synth.  In addition, you'll most likely
>  have a snake of cables running from the MOTU interface over
>  to the modular synth, which is perhaps not ideal in a small
>  studio.
>
>  The least expensive MOTU interface with this capability
>  retails for $549.  A slightly less expensive alternative, at
>  the interface side, is the PreSonus 1818VSL (retail $499),
>  which has an ADAT lightpipe output.  This should connect
>  neatly to the Expert Sleepers ES-3 synth module, which
>  outputs synth-level signals.
>
>  Either the MOTU or the PreSonus should work (again, in theory
>  -- untested) with Csound, because Csound doesn't care if it's
>  transmitting audio with a DC offset.  You would just select
>  the audio channel as the instr output and then send it the
>  a-rate signal of your choosing.
>
>  At that point, Csound could act as the intermediary in a
>  hybrid system.  It could receive OSC messages from, for example,
>  touchOSC on an iPad, translate them into audio, and send them
>  on to the modular synth.  I'd love to try this, but it would be
>  a wee bit expensive to set up and test, when it might not work....
>
>     View this message in context:
>     http://csound.1045644.n5.nabble.com/MIDI-Output-Timing-tp5730695p5730728.html
>     Sent from the Csound - General mailing list archive at Nabble.com.



Send bugs reports to the Sourceforge bug trackers
csound6:
            https://sourceforge.net/p/csound/tickets/
csound5:
            https://sourceforge.net/p/csound/bugs/
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"