Howdy, so I'm making some tests, and I see that my [notein] is sending notes at exact DSP cycles, which may make sense I guess, but is kind of a bummer. I'd like to know why is that anyway...
And how about when you have several values coming from [ctlin] for example? Does only one of them get sent out in sync with DSP?
cheers
On 2015-07-13 07:33, Alexandre Torres Porres wrote:
Howdy, so I'm making some tests, and I see that my [notein] is sending notes at exact DSP cycles, which may make sense I guess, but is kind of a bummer. I'd like to know why is that anyway...
And how about when you have several values coming from [ctlin] for example? Does only one of them get sent out in sync with DSP?
just to see whether i understand the question correctly: so the problem is, that a message emitted by [ctlout] is nto properly timestamped like a message emitted by (say) [metro]? that is, even if you use the [v*] family of objects, you don't get sample-accurate timing, right?
while i do believe that the above assumptions are right (i haven't tested though), i wonder how you set up your tests: basic MIDI isn't very good at timing at all, just relying that 31.25kBd are "fast enough", which is a very bad metric. so how do you generate you MIDI events to be properly alligned with some sample clock?
fgmasdr IOhannes
even if you use the [v*] family of objects, you don't get sample-accurate timing, right?
I used vline~ to convert [ctlin] to audio and it seems it only converter one value for the whole block, so yeah
2015-07-13 4:25 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2015-07-13 07:33, Alexandre Torres Porres wrote:
Howdy, so I'm making some tests, and I see that my [notein] is sending notes at exact DSP cycles, which may make sense I guess, but is kind of a bummer. I'd like to know why is that anyway...
And how about when you have several values coming from [ctlin] for
example?
Does only one of them get sent out in sync with DSP?
just to see whether i understand the question correctly: so the problem is, that a message emitted by [ctlout] is nto properly timestamped like a message emitted by (say) [metro]? that is, even if you use the [v*] family of objects, you don't get sample-accurate timing, right?
while i do believe that the above assumptions are right (i haven't tested though), i wonder how you set up your tests: basic MIDI isn't very good at timing at all, just relying that 31.25kBd are "fast enough", which is a very bad metric. so how do you generate you MIDI events to be properly alligned with some sample clock?
fgmasdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
so how do you generate you MIDI events to be properly alligned with some sample clock?
I'm not sure, I'm just using regular MIDI input keyboard gear
2015-07-13 4:25 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2015-07-13 07:33, Alexandre Torres Porres wrote:
Howdy, so I'm making some tests, and I see that my [notein] is sending notes at exact DSP cycles, which may make sense I guess, but is kind of a bummer. I'd like to know why is that anyway...
And how about when you have several values coming from [ctlin] for
example?
Does only one of them get sent out in sync with DSP?
just to see whether i understand the question correctly: so the problem is, that a message emitted by [ctlout] is nto properly timestamped like a message emitted by (say) [metro]? that is, even if you use the [v*] family of objects, you don't get sample-accurate timing, right?
while i do believe that the above assumptions are right (i haven't tested though), i wonder how you set up your tests: basic MIDI isn't very good at timing at all, just relying that 31.25kBd are "fast enough", which is a very bad metric. so how do you generate you MIDI events to be properly alligned with some sample clock?
fgmasdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 07/13/2015 09:44 AM, Alexandre Torres Porres wrote:
so how do you generate you MIDI events to be properly alligned with some sample clock?
I'm not sure, I'm just using regular MIDI input keyboard gear
in that case, i wouldn't bother about the Pd side. you are basically arguing that having the note-in messages to be alway 64 sample aligned "cannot be right" (which is conceptually true), but in practice you have no way of controlling *when* the note-in messages actually *should* appear (so quantizing them to 64 samples is as good as anything else).
there are plenty of simplifications of the real world in all software you use. unless you hit a specific problem, there is little reason to complexify them.
so to return to your original question:
On 07/13/2015 07:33 AM, Alexandre Torres Porres wrote:
I'd like to know why is that anyway...
it's because Pd calculates all messages (and to be precise: DSP as well) in bursts at the block boundaries. this has practical reasons. eg. no known operating system would allow you to process messages (interrupts, callbacks,...) "on-time" with infinitely precise timestamps in zero time. so you need to buffer anyhow.
now Pd maintains timestamps for internally generated messages, to acchieve "infinitely precise timing". but this only works if Pd knows when the events actually need to be scheduled. most MIDI apis do not give you precise timestamps. So whenever Pd asks for any MIDI message in the queue (which Pd does at the block boundaries), the system just delivers the messages that arrived, without telling Pd when they actually arrived on the hardware.
btw, *some* MIDI APIs (e.g. jack) have timestamps, even though Pd does not use them.
And how about when you have several values coming from [ctlin] for
example?
good question. In real world, sending a MIDI-event takes time. and sending two events takes (about) double time. so if you manage to press to keys on your MIDI keyboard at *exactly the same time*, the note-in messages will still be sent one after the other and you get a slight arpeggio. (not very prominent with two keys; but a known problem if you want to play e.g. clusters)
gfdsr IOhannes
good question. In real world, sending a MIDI-event takes time. and sending two events takes (about) double time.
using usb keyboard that your system see as a midi device, you are no more limited to this 32KBit serial line. so, even if messages are send one after the other, they are send at usb speed...
cheers c
so if you manage to press to keys on your MIDI keyboard at *exactly the same time*, the note-in messages will still be sent one after the other and you get a slight arpeggio. (not very prominent with two keys; but a known problem if you want to play e.g. clusters)
gfdsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2015-07-13 11:28, Cyrille Henry wrote:
good question. In real world, sending a MIDI-event takes time. and sending two events takes (about) double time.
using usb keyboard that your system see as a midi device, you are no more limited to this 32KBit serial line. so, even if messages are send one after the other, they are send at usb speed...
yes and no. i think the MIDI specs are not really clear about such applications e.g. when sending MIDI events in-between applications, you can get even faster than USB-speed.
afaik, the only time the MIDI specs speak about (exact) timing is referring to the 32kbd transmission speed.
gmsdr IOhannes
i seem to have used "applications" with two different meanings.
On 2015-07-13 11:34, IOhannes m zmoelnig wrote:
yes and no. i think the MIDI specs are not really clear about such applications e.g.
here, "applications" should read "use cases".
when sending MIDI events in-between applications, you can get even
here, "applications" means "software programs".
faster than USB-speed.
fgamsdr IOhannes
Le 13/07/2015 07:33, Alexandre Torres Porres a écrit :
Howdy, so I'm making some tests, and I see that my [notein] is sending notes at exact DSP cycles, which may make sense I guess, but is kind of a bummer. I'd like to know why is that anyway...
all pd control data are computed between audio block, it's not just midi message.
And how about when you have several values coming from [ctlin] for example? Does only one of them get sent out in sync with DSP?
no, all of them. but you may have many in 0 logical time.
see atttachement :
the metro output value every micro second. timer can attest that all value are send.
but if you have a look at the recorded wav file, you'll see that value are changed every 1.6ms on my computer : i.e : blocksize (64) / audio frequency (48 000) in fact, values are changed 1600 times between every audio block, and stable for a block.
cheers c
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list