Re: [PD] OSC limitations in Vanilla
Both of you are right. The basis for OSC timetags are of course the (NTP) system time, because that's usually the only shared time source between different apps. However, if you schedule several events in a DSP tick, you don't want to get the current ystem time for each event, because this will cause unnecessary jitter. What you can do instead is get the system time *once* per DSP tick and use that as the basis for scheduling/dispatching events within the tick. This is more or less what Supercollider does, BTW. However, since Pd DSP tick computation itself can be very jittery for large hardware buffer sizes, this is not sufficient. There are basically two solutions, afaict: a) use some dejittering/smoothing algorithm. Scsynth, for exampple, uses a DLL to filter the system time. b) only get the system time for the very first DSP tick and for all subsequent DSP ticks increment by the *logical* block duration. This allows for sample accurate *relative* timing, but the absolute timing can suffer from clock drift. This is the default behavior of Supernova and some people actually experience problems in longer performances. --- Generally, time synchronization between apps is a fundamental (unsolved) problem in computer music. See the following discussion for a starter: https://github.com/supercollider/supercollider/issues/2939. Christof On 18.04.2021 22:32, IOhannes m zmölnig wrote: On 4/18/21 17:06, Martin Peach wrote: On Sun, Apr 18, 2021 at 6:06 AM IOhannes m zmölnig wrote: I don't really like the timestamp implementation in mrpeach (as it uses real time, rather than logical time), but better this than nothing... Logical time timestamps would only be accurate inside of the Pd instance. i tend to disagree. there are basically two use-cases for timetags: - reducing jitter when synthesising events on the receiver e.g. i want to trigger a drum-synth exactly every 100ms - reducing jitter when analysing events from the sender e.g. i want to measure the period between two mocap frames neither of these use-cases warrant system time. here's a real world example: if i use Pd to send events to my drum-synth, and i want these events to be exactly 100ms apart so I'm driving it with a [metro 100], the real time of these ticks will be very jittery (depending on all sorts of things, starting with the audio buffer of Pd), up to dozens of ms. if i codify this jitter in the timestamps, then any law abiding receive will have to do their best to reproduce this jitter. what is the value in that? the only way to schedule two events at exact times I see is to use some "ideal" time - in Pd this is the logical time. but it would not conform to any OSC specification. i checked and double checked the specs but could not find anything about this. where do you get the idea that the OSC specs mandate wall clock time? OSC-1.0 speaks about "NTP format" (but this is just the structure of the 64 bits data chunk) and "the number of seconds since midnight on January 1, 1900" (but it doesn't say whether this is supposed to be wallclock or idealized) > It could be added as an option a flag or similar would be great. there probably are use-cases where real time makes sense, why not be able to cater for both. f,dst IOhannes ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] OSC limitations in Vanilla
On 4/18/21 17:06, Martin Peach wrote: On Sun, Apr 18, 2021 at 6:06 AM IOhannes m zmölnig wrote: I don't really like the timestamp implementation in mrpeach (as it uses real time, rather than logical time), but better this than nothing... Logical time timestamps would only be accurate inside of the Pd instance. i tend to disagree. there are basically two use-cases for timetags: - reducing jitter when synthesising events on the receiver e.g. i want to trigger a drum-synth exactly every 100ms - reducing jitter when analysing events from the sender e.g. i want to measure the period between two mocap frames neither of these use-cases warrant system time. here's a real world example: if i use Pd to send events to my drum-synth, and i want these events to be exactly 100ms apart so I'm driving it with a [metro 100], the real time of these ticks will be very jittery (depending on all sorts of things, starting with the audio buffer of Pd), up to dozens of ms. if i codify this jitter in the timestamps, then any law abiding receive will have to do their best to reproduce this jitter. what is the value in that? the only way to schedule two events at exact times I see is to use some "ideal" time - in Pd this is the logical time. but it would not conform to any OSC specification. i checked and double checked the specs but could not find anything about this. where do you get the idea that the OSC specs mandate wall clock time? OSC-1.0 speaks about "NTP format" (but this is just the structure of the 64 bits data chunk) and "the number of seconds since midnight on January 1, 1900" (but it doesn't say whether this is supposed to be wallclock or idealized) > It could be added as an option a flag or similar would be great. there probably are use-cases where real time makes sense, why not be able to cater for both. f,dst IOhannes OpenPGP_signature Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] OSC limitations in Vanilla
Em dom., 18 de abr. de 2021 às 09:15, mitchell turner < mmturner2...@gmail.com> escreveu: > Alexandre, > I rewrote the TouchOSC templates using only vanilla (at least I think it > is vanilla). > It is :) cool Not sure this is what you are looking for but thought I’d reply. > not really, but thanks anyway ;) or, in a sense, you're saying "I find no limitation" cheers ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] OSC limitations in Vanilla
On Sun, Apr 18, 2021 at 6:06 AM IOhannes m zmölnig wrote: > > I don't really like the timestamp implementation in mrpeach (as it uses real > time, rather than logical time), but better this than nothing... Logical time timestamps would only be accurate inside of the Pd instance. It could be added as an option but it would not conform to any OSC specification. Martin ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] OSC limitations in Vanilla
Alexandre, I rewrote the TouchOSC templates using only vanilla (at least I think it is vanilla). These templates allow one to easily use the TouchOSC program on an iPhone/iPad and Pd. Not sure this is what you are looking for but thought I’d reply. If you are interested, you can take a look at the patches here: http://home.lagrange.edu/mturner/MitchWebSite/max_and_pd_stuff.html <http://home.lagrange.edu/mturner/MitchWebSite/max_and_pd_stuff.html> — Mitch > On Apr 18, 2021, at 6:00 AM, pd-list-requ...@lists.iem.at wrote: > > Message: 4 > Date: Sun, 18 Apr 2021 04:21:57 -0300 > From: Alexandre Torres Porres mailto:por...@gmail.com>> > To: Pd-List mailto:pd-list@lists.iem.at>> > Subject: [PD] OSC limitations in Vanilla > Message-ID: ><mailto:caeasfmjz74e69yzi8x472hafjh55e2np+mzw9gsvpauvn3n...@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > I asked this on the facebook group, thought I'd ask it here as well. Who > cannot be happy with vanilla's OSC support and still needs mrpeach and > stuff? I mean, really really need as in there's no way to deal with such > OSC tasks in Vanilla. Tell me what exactly please... I know that it can > happen and how, I just wanted examples in the real world, and I also > believe Vanilla is fine for most use cases. > > I just never use OSC as all I do is inside Pd anyway :) > > I see [netsend]/[netreceive] make [udpsend]/[udpreceive] obsolete these > days for OSC... but we also have [routeOSC] and [packOSC], and in Vanilla's > documentation we see this: ~*no attempt is made here to clearly > distinguish between the OSC address (symbols) and the following data, nor > between blobs and lists of numbers - it is assumed that you know what types > the message should contain. You can alternatively use the OSC objects from > mrpeach which have more features than these.*~ > > cheers > -- next part -- > An HTML attachment was scrubbed... > URL: > <http://lists.puredata.info/pipermail/pd-list/attachments/20210418/c7ec61f9/attachment-0001.htm > > <http://lists.puredata.info/pipermail/pd-list/attachments/20210418/c7ec61f9/attachment-0001.htm>> > > -- ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] OSC limitations in Vanilla
I think I had problems in the past for not having [routeOSC] and [packOSC] when sending/receiving from other software such as reaper, but I can't confirm anymore. Other softwares will work with mrpeach, but not necessarily with vanilla. It's also convenient to use routeOSC for a cleaner patch structure, as it allows a route-style tree sorting. I asked this on the facebook group, thought I'd ask it here as well. Who cannot be happy with vanilla's OSC support and still needs mrpeach and stuff? I mean, really really need as in there's no way to deal with such OSC tasks in Vanilla. Tell me what exactly please... I know that it can happen and how, I just wanted examples in the real world, and I also believe Vanilla is fine for most use cases. I just never use OSC as all I do is inside Pd anyway :) I see [netsend]/[netreceive] make [udpsend]/[udpreceive] obsolete these days for OSC... but we also have [routeOSC] and [packOSC], and in Vanilla's documentation we see this: ~/no attempt is made here to clearly distinguish between the OSC address (symbols) and the following data, nor between blobs and lists of numbers - it is assumed that you know what types the message should contain. You can alternatively use the OSC objects from mrpeach which have more features than these./~ ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] OSC limitations in Vanilla
Am 18. April 2021 09:21:57 MESZ schrieb Alexandre Torres Porres : > I asked this on the facebook group, thought I'd ask it here as well. > Who > cannot be happy with vanilla's OSC support and still needs mrpeach and > stuff? I mean, really really need as in there's no way to deal with > such > OSC tasks in Vanilla. simple: timestamps and bundles. if your sender application uses bundles and you can't change that, you are stuck with mrpeach. i think practically all applications I've written that send OSC data (to Pd,...) use bundles (except for toy apps, or during class when I didn't want to get sidetracked). if jitter is a problem (and often it is, if you are transmitting notes or periodically sampled data), you *need* timestamps. I don't really like the timestamp implementation in mrpeach (as it uses real time, rather than logical time), but better this than nothing... mfg.hft.fsl IOhannes ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] OSC limitations in Vanilla
I asked this on the facebook group, thought I'd ask it here as well. Who cannot be happy with vanilla's OSC support and still needs mrpeach and stuff? I mean, really really need as in there's no way to deal with such OSC tasks in Vanilla. Tell me what exactly please... I know that it can happen and how, I just wanted examples in the real world, and I also believe Vanilla is fine for most use cases. I just never use OSC as all I do is inside Pd anyway :) I see [netsend]/[netreceive] make [udpsend]/[udpreceive] obsolete these days for OSC... but we also have [routeOSC] and [packOSC], and in Vanilla's documentation we see this: ~*no attempt is made here to clearly distinguish between the OSC address (symbols) and the following data, nor between blobs and lists of numbers - it is assumed that you know what types the message should contain. You can alternatively use the OSC objects from mrpeach which have more features than these.*~ cheers ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
