Re: [PD] data structures in abstractions
Thanks Jonathan You are a magician. You said it works, so now it does no bugs. The only thing I can't get rid of is the datawindow name appearing in the graph on parent. No matter how many times I turn it off, once I save it and load it again, it comes back on. The name of the main graph on parent does not show, only of the subpatch I attached the abstraction here Cheers Eldad randomPolygon.pd Description: Binary data randomPolygon-help.pd Description: Binary data On 2012-11-27, at 11:11 PM, Jonathan Wilkes wrote: > - Original Message - > >> From: eldad tsabary >> To: pd-list@iem.at >> Cc: >> Sent: Tuesday, November 27, 2012 10:31 PM >> Subject: Re: [PD] data structures in abstractions >> >> G reat >> It works fairly well with graph on parent of the subpatch (datawindow) >> However, if I try to make the entire patch into an abstraction and have a >> graph >> on parent of the main window containing the graph from the subpatch it >> doesn't work so well. >> It seems to display in another patch but buggy, and it also doesn't allow me >> to drag and drop the polygon joints. >> Do you know if this should work and how? >> Many thanks again >> Eldad > > Works for me-- I don't get any difference between gop subpatch (or nested > subpatches) > vs. gop abstraction. I can click and drag the joints the same as before. > > What is buggy? > > -Jonathan > >> >> >> >> >> >> >> On 2012-11-27, at 3:09 PM, Jonathan Wilkes wrote: >> >>> - Original Message - >>> From: eldad tsabary To: pd-list@iem.at Cc: Sent: Tuesday, November 27, 2012 1:48 PM Subject: [PD] data structures in abstractions Hello all Is there a way to include a data structure graphical shape >> (filledpolygon for example) inside an abstraction's graph on parent? I saw that when trying to add a graph on parent in the data window it >> messes up everything. Thanks Eldad >>> >>> Hi Eldad, >>> You have to adjust the x range and y range in the canvas properties >>> to >> be "in >>> agreement" with the x and y size in the canvas properties. So if x >> size is 85, make >>> the range 0 to 84, and do a similar process for the y. >>> I think it's done this way for "Put" menu arrays where >> you would have a different >>> y range depending on the situation. However, drawing instructions like >> [plot] give the >>> ability to scale the values of a scalar to some screen pixel range so I >> don't get why >>> this "range" business is part of the canvas properties (or the >> canvas class for that >>> matter). >>> >>> -Jonathan >>> ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list >> >> >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] data structures in abstractions
- Original Message - > From: eldad tsabary > To: pd-list@iem.at > Cc: > Sent: Tuesday, November 27, 2012 10:31 PM > Subject: Re: [PD] data structures in abstractions > >G reat > It works fairly well with graph on parent of the subpatch (datawindow) > However, if I try to make the entire patch into an abstraction and have a > graph > on parent of the main window containing the graph from the subpatch it > doesn't work so well. > It seems to display in another patch but buggy, and it also doesn't allow me > to drag and drop the polygon joints. > Do you know if this should work and how? > Many thanks again > Eldad Works for me-- I don't get any difference between gop subpatch (or nested subpatches) vs. gop abstraction. I can click and drag the joints the same as before. What is buggy? -Jonathan > > > > > > > On 2012-11-27, at 3:09 PM, Jonathan Wilkes wrote: > >> - Original Message - >> >>> From: eldad tsabary >>> To: pd-list@iem.at >>> Cc: >>> Sent: Tuesday, November 27, 2012 1:48 PM >>> Subject: [PD] data structures in abstractions >>> >>> Hello all >>> Is there a way to include a data structure graphical shape > (filledpolygon for >>> example) inside an abstraction's graph on parent? >>> I saw that when trying to add a graph on parent in the data window it > messes up >>> everything. >>> Thanks >>> Eldad >> >> Hi Eldad, >> You have to adjust the x range and y range in the canvas properties to > be "in >> agreement" with the x and y size in the canvas properties. So if x > size is 85, make >> the range 0 to 84, and do a similar process for the y. >> I think it's done this way for "Put" menu arrays where > you would have a different >> y range depending on the situation. However, drawing instructions like > [plot] give the >> ability to scale the values of a scalar to some screen pixel range so I > don't get why >> this "range" business is part of the canvas properties (or the > canvas class for that >> matter). >> >> -Jonathan >> >>> >>> >>> >>> ___ >>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] data structures in abstractions
Great It works fairly well with graph on parent of the subpatch (datawindow) However, if I try to make the entire patch into an abstraction and have a graph on parent of the main window containing the graph from the subpatch it doesn't work so well. It seems to display in another patch but buggy, and it also doesn't allow me to drag and drop the polygon joints. Do you know if this should work and how? Many thanks again Eldad On 2012-11-27, at 3:09 PM, Jonathan Wilkes wrote: > - Original Message - > >> From: eldad tsabary >> To: pd-list@iem.at >> Cc: >> Sent: Tuesday, November 27, 2012 1:48 PM >> Subject: [PD] data structures in abstractions >> >> Hello all >> Is there a way to include a data structure graphical shape (filledpolygon >> for >> example) inside an abstraction's graph on parent? >> I saw that when trying to add a graph on parent in the data window it messes >> up >> everything. >> Thanks >> Eldad > > Hi Eldad, > You have to adjust the x range and y range in the canvas properties to > be "in > agreement" with the x and y size in the canvas properties. So if x size is > 85, make > the range 0 to 84, and do a similar process for the y. > I think it's done this way for "Put" menu arrays where you would have a > different > y range depending on the situation. However, drawing instructions like > [plot] give the > ability to scale the values of a scalar to some screen pixel range so I don't > get why > this "range" business is part of the canvas properties (or the canvas class > for that > matter). > > -Jonathan > >> >> >> >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] data structures in abstractions
- Original Message - > From: eldad tsabary > To: pd-list@iem.at > Cc: > Sent: Tuesday, November 27, 2012 1:48 PM > Subject: [PD] data structures in abstractions > > Hello all > Is there a way to include a data structure graphical shape (filledpolygon for > example) inside an abstraction's graph on parent? > I saw that when trying to add a graph on parent in the data window it messes > up > everything. > Thanks > Eldad Hi Eldad, You have to adjust the x range and y range in the canvas properties to be "in agreement" with the x and y size in the canvas properties. So if x size is 85, make the range 0 to 84, and do a similar process for the y. I think it's done this way for "Put" menu arrays where you would have a different y range depending on the situation. However, drawing instructions like [plot] give the ability to scale the values of a scalar to some screen pixel range so I don't get why this "range" business is part of the canvas properties (or the canvas class for that matter). -Jonathan > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] data structures in abstractions
Hello all Is there a way to include a data structure graphical shape (filledpolygon for example) inside an abstraction's graph on parent? I saw that when trying to add a graph on parent in the data window it messes up everything. Thanks Eldad ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-11-27 18:06, Miller Puckette wrote: > better on some underlying OS time-tagging mechanism (for instance > by exploiting whatever portmidi does). But I have to admit I've > never treated this as a high priority (which one might take as an > implied value judgement about MIDI). > i share any bad sentiments about midi. anyhow, i think jack-midi allows for timestamping as well. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlC1BBMACgkQkX2Xpv6ydvS/RQCfYqw/3yD6MvNkl/MPdTYbCnBt OCsAnRPVNnxLLrpU8RghzctkCAscbYxO =21d7 -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
cool, thanks. better than a ifdef, a startup flag! cheers c Le 27/11/2012 18:50, Miller Puckette a écrit : I believe if you edit s_midi.c and change: if (midi_outqueue[midi_outtail].q_time <= midirealtime) to if (1) and if (midi_inqueue[midi_intail].q_time <= logicaltime) also to if (1) that will make it fast-as-possible. The queueing code should probably be surrounded by an ifdef to make this easier (perhaps someday...) cheers M On Tue, Nov 27, 2012 at 06:23:15PM +0100, Cyrille Henry wrote: Is there a way to bypass all of this? my pd usage usually imply sending and receiving as fast as possible. sending delay usually annoy me. cheers c Le 27/11/2012 18:06, Miller Puckette a écrit : Pd tries to time-stamp MIDI on input and tries to delay sending MIDI output until the correct time; but Pd's accuracy in doing this is limited by the fact that it can't input or output MIID while it is either sleeping or running (only when the scheduler polls for what-to-do-next after either a task or a sleep has finished.) It would be more accurate for Pd to rely on either software interrupts or even better on some underlying OS time-tagging mechanism (for instance by exploiting whatever portmidi does). But I have to admit I've never treated this as a high priority (which one might take as an implied value judgement about MIDI). cheers Miller On Tue, Nov 27, 2012 at 11:44:06AM +0100, Cyrille Henry wrote: Le 27/11/2012 10:36, IOhannes m zmoelnig a écrit : ... with MIDI, Pd doesn't do any buffering and no synchronisation to some external clock is done, so messages appear in bursts which you notice as a inaccurate timing. There is 1 strange thing however : pd did some kind of buffering with midi, in order to synchronise with audio out. if you configure 100ms audio latency, then a midi loop will be between 100 and 105ms. with 10ms audio buffer out, the midi loop is between 10 and 15ms. but this buffer should not change anything on timing except adding latency. cheers c ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
I believe if you edit s_midi.c and change: if (midi_outqueue[midi_outtail].q_time <= midirealtime) to if (1) and if (midi_inqueue[midi_intail].q_time <= logicaltime) also to if (1) that will make it fast-as-possible. The queueing code should probably be surrounded by an ifdef to make this easier (perhaps someday...) cheers M On Tue, Nov 27, 2012 at 06:23:15PM +0100, Cyrille Henry wrote: > Is there a way to bypass all of this? > my pd usage usually imply sending and receiving as fast as possible. > sending delay usually annoy me. > cheers > c > > > Le 27/11/2012 18:06, Miller Puckette a écrit : > >Pd tries to time-stamp MIDI on input and tries to delay sending MIDI output > >until the correct time; but Pd's accuracy in doing this is limited by the > >fact that it can't input or output MIID while it is either sleeping or > >running > >(only when the scheduler polls for what-to-do-next after either a task or a > >sleep has finished.) > > > >It would be more accurate for Pd to rely on either software interrupts or > >even > >better on some underlying OS time-tagging mechanism (for instance by > >exploiting > >whatever portmidi does). But I have to admit I've never treated this as a > >high > >priority (which one might take as an implied value judgement about MIDI). > > > >cheers > >Miller > > > >On Tue, Nov 27, 2012 at 11:44:06AM +0100, Cyrille Henry wrote: > >> > >> > >>Le 27/11/2012 10:36, IOhannes m zmoelnig a écrit : > >>... > >>>with MIDI, Pd doesn't do any buffering and no synchronisation to some > >>>external clock is done, so messages appear in bursts which you notice > >>>as a inaccurate timing. > >> > >>There is 1 strange thing however : pd did some kind of buffering with midi, > >>in order to synchronise with audio out. > >>if you configure 100ms audio latency, then a midi loop will be between 100 > >>and 105ms. > >>with 10ms audio buffer out, the midi loop is between 10 and 15ms. > >>but this buffer should not change anything on timing except adding latency. > >>cheers > >>c > >> > >>___ > >>Pd-list@iem.at mailing list > >>UNSUBSCRIBE and account-management -> > >>http://lists.puredata.info/listinfo/pd-list > > > >___ > >Pd-list@iem.at mailing list > >UNSUBSCRIBE and account-management -> > >http://lists.puredata.info/listinfo/pd-list > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
Is there a way to bypass all of this? my pd usage usually imply sending and receiving as fast as possible. sending delay usually annoy me. cheers c Le 27/11/2012 18:06, Miller Puckette a écrit : Pd tries to time-stamp MIDI on input and tries to delay sending MIDI output until the correct time; but Pd's accuracy in doing this is limited by the fact that it can't input or output MIID while it is either sleeping or running (only when the scheduler polls for what-to-do-next after either a task or a sleep has finished.) It would be more accurate for Pd to rely on either software interrupts or even better on some underlying OS time-tagging mechanism (for instance by exploiting whatever portmidi does). But I have to admit I've never treated this as a high priority (which one might take as an implied value judgement about MIDI). cheers Miller On Tue, Nov 27, 2012 at 11:44:06AM +0100, Cyrille Henry wrote: Le 27/11/2012 10:36, IOhannes m zmoelnig a écrit : ... with MIDI, Pd doesn't do any buffering and no synchronisation to some external clock is done, so messages appear in bursts which you notice as a inaccurate timing. There is 1 strange thing however : pd did some kind of buffering with midi, in order to synchronise with audio out. if you configure 100ms audio latency, then a midi loop will be between 100 and 105ms. with 10ms audio buffer out, the midi loop is between 10 and 15ms. but this buffer should not change anything on timing except adding latency. cheers c ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
Pd tries to time-stamp MIDI on input and tries to delay sending MIDI output until the correct time; but Pd's accuracy in doing this is limited by the fact that it can't input or output MIID while it is either sleeping or running (only when the scheduler polls for what-to-do-next after either a task or a sleep has finished.) It would be more accurate for Pd to rely on either software interrupts or even better on some underlying OS time-tagging mechanism (for instance by exploiting whatever portmidi does). But I have to admit I've never treated this as a high priority (which one might take as an implied value judgement about MIDI). cheers Miller On Tue, Nov 27, 2012 at 11:44:06AM +0100, Cyrille Henry wrote: > > > Le 27/11/2012 10:36, IOhannes m zmoelnig a écrit : > ... > >with MIDI, Pd doesn't do any buffering and no synchronisation to some > >external clock is done, so messages appear in bursts which you notice > >as a inaccurate timing. > > There is 1 strange thing however : pd did some kind of buffering with midi, > in order to synchronise with audio out. > if you configure 100ms audio latency, then a midi loop will be between 100 > and 105ms. > with 10ms audio buffer out, the midi loop is between 10 and 15ms. > but this buffer should not change anything on timing except adding latency. > cheers > c > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] firewire is dead?
oh really? that's interesting. The later numbers come from a Ubuntu machine which isn't set up for sound at all, so when I compare those with a os x machine and the "famous" rme drivers the numbers are still impressive. Am 27.11.2012 um 17:47 schrieb Miller Puckette : > If I'm reading rour post right, you're specifying 20 msec latency and getting > about 22, which is OK, but I think you should be able to get lower latencies > (i.e., I don't see that numbers like 21.9012 are too good to be true - > those are typical Macintosh latencies but I think in linux you should be > able to do much better.) > > cheers > Miller > > On Tue, Nov 27, 2012 at 05:15:35PM +0100, Max wrote: >> you are right - those numbers seem to be to good to be true. On the other >> hand I followed the instructions in the latency patch and don't know what >> could have been wrong. >> >> Am 26.11.2012 um 19:04 schrieb Miller Puckette : >> >>> Hmm - I'm getting latencies between 6 and 7 (Fedora 17, Core 7200, INTEL >>> "HDA", latest Pd from git, but I think Pd 0.43 should do similar). >>> >>> cheers >>> Miller >>> >>> On Mon, Nov 26, 2012 at 06:53:31PM +0100, Max wrote: Am 26.11.2012 um 16:18 schrieb J Oliver : > Hi Max, > > Is it possible for you to test this same card in linux? > > J I wanted to do this, but I don't have a linux machine with firewire, so i can't test the ffado driver for the card. I wanted to try out the class compliant mode, but there is a bug in ALSA which prevents it to work. see http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28935.html I didn't wanted to get started recompiling the kernel for this. sorry. So in theory it should work, but only if you remove the bug in the ALSA part. for the record i compared the on board intel card of the linux machine, the result is quite impressive, i don't think it can get any better: /doc/7.stuff/tools/latency.pd Sampling rate 44100 Hz, delay 20 ms Blocksize 64 Ubuntu 12.04 Intel® Core™ i3 CPU 550 @ 3.20GHz × 4 Latency HDA Intel (hardware) print: 21.9012 print: 21.9037 print: 21.9063 print: 21.9088 print: 21.9114 print: 21.914 print: 21.9165 print: 21.9191 print: 21.9217 print: 21.8834 print: 21.886 print: 21.8885 print: 21.891 print: 21.8936 print: 21.8961 print: 21.8986 print: 21.9012 print: 21.9037 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list >> >> >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] firewire is dead?
If I'm reading rour post right, you're specifying 20 msec latency and getting about 22, which is OK, but I think you should be able to get lower latencies (i.e., I don't see that numbers like 21.9012 are too good to be true - those are typical Macintosh latencies but I think in linux you should be able to do much better.) cheers Miller On Tue, Nov 27, 2012 at 05:15:35PM +0100, Max wrote: > you are right - those numbers seem to be to good to be true. On the other > hand I followed the instructions in the latency patch and don't know what > could have been wrong. > > Am 26.11.2012 um 19:04 schrieb Miller Puckette : > > > Hmm - I'm getting latencies between 6 and 7 (Fedora 17, Core 7200, INTEL > > "HDA", latest Pd from git, but I think Pd 0.43 should do similar). > > > > cheers > > Miller > > > > On Mon, Nov 26, 2012 at 06:53:31PM +0100, Max wrote: > >> Am 26.11.2012 um 16:18 schrieb J Oliver : > >> > >>> Hi Max, > >>> > >>> Is it possible for you to test this same card in linux? > >>> > >>> J > >> > >> I wanted to do this, but I don't have a linux machine with firewire, so i > >> can't test the ffado driver for the card. I wanted to try out the class > >> compliant mode, but there is a bug in ALSA which prevents it to work. see > >> http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28935.html > >> I didn't wanted to get started recompiling the kernel for this. sorry. So > >> in theory it should work, but only if you remove the bug in the ALSA part. > >> > >> for the record i compared the on board intel card of the linux machine, > >> the result is quite impressive, i don't think it can get any better: > >> > >> /doc/7.stuff/tools/latency.pd > >> Sampling rate 44100 Hz, delay 20 ms Blocksize 64 > >> Ubuntu 12.04 Intel® Core™ i3 CPU 550 @ 3.20GHz × 4 > >> Latency HDA Intel (hardware) > >> > >> print: 21.9012 > >> print: 21.9037 > >> print: 21.9063 > >> print: 21.9088 > >> print: 21.9114 > >> print: 21.914 > >> print: 21.9165 > >> print: 21.9191 > >> print: 21.9217 > >> print: 21.8834 > >> print: 21.886 > >> print: 21.8885 > >> print: 21.891 > >> print: 21.8936 > >> print: 21.8961 > >> print: 21.8986 > >> print: 21.9012 > >> print: 21.9037 > >> ___ > >> Pd-list@iem.at mailing list > >> UNSUBSCRIBE and account-management -> > >> http://lists.puredata.info/listinfo/pd-list > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] firewire is dead?
Am 27.11.2012 um 17:02 schrieb J Oliver : >>> for the record i compared the on board intel card of the linux machine, the >>> result is quite impressive, i don't think it can get any better: > I have also gotten the HDA way lower than 20 ms in ubuntu 12.04...! for comparability I've set the delay time in Pd to 20. So that's a constant you should subtract from the latency measured by the latency.pd patch. The rest of ~1.9 ms is a little hard to believe. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] firewire is dead?
you are right - those numbers seem to be to good to be true. On the other hand I followed the instructions in the latency patch and don't know what could have been wrong. Am 26.11.2012 um 19:04 schrieb Miller Puckette : > Hmm - I'm getting latencies between 6 and 7 (Fedora 17, Core 7200, INTEL > "HDA", latest Pd from git, but I think Pd 0.43 should do similar). > > cheers > Miller > > On Mon, Nov 26, 2012 at 06:53:31PM +0100, Max wrote: >> Am 26.11.2012 um 16:18 schrieb J Oliver : >> >>> Hi Max, >>> >>> Is it possible for you to test this same card in linux? >>> >>> J >> >> I wanted to do this, but I don't have a linux machine with firewire, so i >> can't test the ffado driver for the card. I wanted to try out the class >> compliant mode, but there is a bug in ALSA which prevents it to work. see >> http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28935.html >> I didn't wanted to get started recompiling the kernel for this. sorry. So in >> theory it should work, but only if you remove the bug in the ALSA part. >> >> for the record i compared the on board intel card of the linux machine, the >> result is quite impressive, i don't think it can get any better: >> >> /doc/7.stuff/tools/latency.pd >> Sampling rate 44100 Hz, delay 20 ms Blocksize 64 >> Ubuntu 12.04 Intel® Core™ i3 CPU 550 @ 3.20GHz × 4 >> Latency HDA Intel (hardware) >> >> print: 21.9012 >> print: 21.9037 >> print: 21.9063 >> print: 21.9088 >> print: 21.9114 >> print: 21.914 >> print: 21.9165 >> print: 21.9191 >> print: 21.9217 >> print: 21.8834 >> print: 21.886 >> print: 21.8885 >> print: 21.891 >> print: 21.8936 >> print: 21.8961 >> print: 21.8986 >> print: 21.9012 >> print: 21.9037 >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Freezes with Pd-Extended and Jack
Two things: 1) in 0.43 there has been a rewrite of audio backend which AFAICT broke jack connectivity. 2) 0.42 branch does not know when jack has died (as in quit or crashed) and therefore hangs pd. This has been fixed in pd-l2ork. Since it is a combination of 1 and 2 there is not a patch per se that can be shared since 0.43 branch uses different code base. Best wishes, Ico > -Original Message- > From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of > Hans-Christoph Steiner > Sent: Tuesday, November 27, 2012 9:51 AM > To: Roman Haefeli > Cc: pd-list@iem.at > Subject: Re: [PD] Freezes with Pd-Extended and Jack > > > Is that the way it was in vanilla 0.42, or did something change in pd-l2ork? > > .hc > > On Nov 27, 2012, at 4:34 AM, Roman Haefeli wrote: > > > > I just tested pd-l2ork and it seems this is exactly how it fixes the > > freeze problem: Turning DSP off does not kill the pd client in jack. > > > > Roman > > > > On Die, 2012-11-27 at 10:20 +0100, Roman Haefeli wrote: > > > >> The problem seems related to the fact that switching DSP also > >> switches the jack client on and off. I think the preferred way would > >> be to be able to switch DSP on/off independently from switching audio > >> back-end on/off. > >> > >> > >> On Mit, 2012-11-21 at 20:35 -0200, Esteban Viveros wrote: > >>> Hello, > >>> > >>> > >>> I'm using pd-extended 0.43.4, installed via Hans-Cristoph Steiner ppa. > >>> I'm using this version because I can't install the stable version in > >>> Ubuntu 12.04. > >>> > >>> > >>> The problem is, when I start pd with Jack in -rt mode or wherever > >>> mode, if I turn on dsp, they work well, but if I turn off, and try > >>> to turn on yet dsp, pd-extended freeze... > >>> > >>> Closing Qjackctl (after some time ubuntu can close that) pd-extended > >>> returns to work, and I can use on alsa directly sucessfull.. > >>> > >>> > >>> Someone knows where I can comunicate this bug to the developers? Is > >>> here the place? > >>> > >>> > >>> Thanks a lot! > >>> > >>> > >>> -- > >>> > >>> > >>> Esteban Viveros > >>> > >>> (27) 8815 7170 > >>> (27) 3066 0359 > >>> (11) 95761 4125 > >>> (11) 2738 7868 > >>> > >>> www.bandpage.com/estebanviveros > >>> > >>> https://www.facebook.com/estebanviveros.art > >>> > >>> http://www.papodecompositor-es.blogspot.com.br/ > >>> > >>> http://expurgacao.art.br/ > >>> > >>> > >>> > >>> ___ > >>> Pd-list@iem.at mailing list > >>> UNSUBSCRIBE and account-management -> > >>> http://lists.puredata.info/listinfo/pd-list > >> > >> > > > > > > > > ___ > > Pd-list@iem.at mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Freezes with Pd-Extended and Jack
I don't know. IIRC, Pd-{vanilla,extended} up to 0.42 behaved as pd-l2ork
does now. Is pd-l2ork based on 0.42? If so, they (Ivica) wouldn't have
had to fix it at all.
Roman
On Die, 2012-11-27 at 09:50 -0500, Hans-Christoph Steiner wrote:
> Is that the way it was in vanilla 0.42, or did something change in pd-l2ork?
>
> .hc
>
> On Nov 27, 2012, at 4:34 AM, Roman Haefeli wrote:
> >
> > I just tested pd-l2ork and it seems this is exactly how it fixes the
> > freeze problem: Turning DSP off does not kill the pd client in jack.
> >
> > Roman
> >
> > On Die, 2012-11-27 at 10:20 +0100, Roman Haefeli wrote:
> >
> >> The problem seems related to the fact that switching DSP also switches
> >> the jack client on and off. I think the preferred way would be to be
> >> able to switch DSP on/off independently from switching audio back-end
> >> on/off.
> >>
> >>
> >> On Mit, 2012-11-21 at 20:35 -0200, Esteban Viveros wrote:
> >>> Hello,
> >>>
> >>>
> >>> I'm using pd-extended 0.43.4, installed via Hans-Cristoph Steiner ppa.
> >>> I'm using this version because I can't install the stable version in
> >>> Ubuntu 12.04.
> >>>
> >>>
> >>> The problem is, when I start pd with Jack in -rt mode or wherever
> >>> mode, if I turn on dsp, they work well, but if I turn off, and try to
> >>> turn on yet dsp, pd-extended freeze...
> >>>
> >>> Closing Qjackctl (after some time ubuntu can close that)
> >>> pd-extended returns to work, and I can use on alsa directly
> >>> sucessfull..
> >>>
> >>>
> >>> Someone knows where I can comunicate this bug to the developers? Is
> >>> here the place?
> >>>
> >>>
> >>> Thanks a lot!
> >>>
> >>>
> >>> --
> >>>
> >>>
> >>> Esteban Viveros
> >>>
> >>> (27) 8815 7170
> >>> (27) 3066 0359
> >>> (11) 95761 4125
> >>> (11) 2738 7868
> >>>
> >>> www.bandpage.com/estebanviveros
> >>>
> >>> https://www.facebook.com/estebanviveros.art
> >>>
> >>> http://www.papodecompositor-es.blogspot.com.br/
> >>>
> >>> http://expurgacao.art.br/
> >>>
> >>>
> >>>
> >>> ___
> >>> Pd-list@iem.at mailing list
> >>> UNSUBSCRIBE and account-management ->
> >>> http://lists.puredata.info/listinfo/pd-list
> >>
> >>
> >
> >
> >
> > ___
> > Pd-list@iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] firewire is dead?
Hi Miller, Is this with the test tone patch? >> >> for the record i compared the on board intel card of the linux machine, the >> result is quite impressive, i don't think it can get any better: I have also gotten the HDA way lower than 20 ms in ubuntu 12.04...! best, J >> >> /doc/7.stuff/tools/latency.pd >> Sampling rate 44100 Hz, delay 20 ms Blocksize 64 >> Ubuntu 12.04 Intel® Core™ i3 CPU 550 @ 3.20GHz × 4 >> Latency HDA Intel (hardware) >> >> print: 21.9012 >> print: 21.9037 >> print: 21.9063 >> print: 21.9088 >> print: 21.9114 >> print: 21.914 >> print: 21.9165 >> print: 21.9191 >> print: 21.9217 >> print: 21.8834 >> print: 21.886 >> print: 21.8885 >> print: 21.891 >> print: 21.8936 >> print: 21.8961 >> print: 21.8986 >> print: 21.9012 >> print: 21.9037 >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Freezes with Pd-Extended and Jack
Is that the way it was in vanilla 0.42, or did something change in pd-l2ork? .hc On Nov 27, 2012, at 4:34 AM, Roman Haefeli wrote: > > I just tested pd-l2ork and it seems this is exactly how it fixes the > freeze problem: Turning DSP off does not kill the pd client in jack. > > Roman > > On Die, 2012-11-27 at 10:20 +0100, Roman Haefeli wrote: > >> The problem seems related to the fact that switching DSP also switches >> the jack client on and off. I think the preferred way would be to be >> able to switch DSP on/off independently from switching audio back-end >> on/off. >> >> >> On Mit, 2012-11-21 at 20:35 -0200, Esteban Viveros wrote: >>> Hello, >>> >>> >>> I'm using pd-extended 0.43.4, installed via Hans-Cristoph Steiner ppa. >>> I'm using this version because I can't install the stable version in >>> Ubuntu 12.04. >>> >>> >>> The problem is, when I start pd with Jack in -rt mode or wherever >>> mode, if I turn on dsp, they work well, but if I turn off, and try to >>> turn on yet dsp, pd-extended freeze... >>> >>> Closing Qjackctl (after some time ubuntu can close that) >>> pd-extended returns to work, and I can use on alsa directly >>> sucessfull.. >>> >>> >>> Someone knows where I can comunicate this bug to the developers? Is >>> here the place? >>> >>> >>> Thanks a lot! >>> >>> >>> -- >>> >>> >>> Esteban Viveros >>> >>> (27) 8815 7170 >>> (27) 3066 0359 >>> (11) 95761 4125 >>> (11) 2738 7868 >>> >>> www.bandpage.com/estebanviveros >>> >>> https://www.facebook.com/estebanviveros.art >>> >>> http://www.papodecompositor-es.blogspot.com.br/ >>> >>> http://expurgacao.art.br/ >>> >>> >>> >>> ___ >>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >> >> > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
Le 27/11/2012 10:36, IOhannes m zmoelnig a écrit : ... with MIDI, Pd doesn't do any buffering and no synchronisation to some external clock is done, so messages appear in bursts which you notice as a inaccurate timing. There is 1 strange thing however : pd did some kind of buffering with midi, in order to synchronise with audio out. if you configure 100ms audio latency, then a midi loop will be between 100 and 105ms. with 10ms audio buffer out, the midi loop is between 10 and 15ms. but this buffer should not change anything on timing except adding latency. cheers c ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
thanks, clear indeed ! JM Le 27 nov. 2012 à 10:36, IOhannes m zmoelnig a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2012-11-26 23:29, Cyrille Henry wrote: >> >> >> Le 26/11/2012 22:38, Jean-Marie Adrien a écrit : >>> Thanks Miller ! -nosound -udiobuf 5 -slepgrain 1 >>> Definitely academic :) >>> >>> But I run intense audio on this PD instance, together with midi >>> driving lights in real time. here are the flags : >>> >>> -rt -noadc -midioutdev 1,2 -audiooutdev 2 -outchannels 8 >>> >>> phasor~ would not do it ? >> phasor~ will do provide a better clock than a metro since pd >> internal time is "perfect". your problem come from jitter between >> "pd time" and "real world time". > > just to clarify: > both [phasor~] and [metro] live in an ideal world with perfect timing. > unfortunately this ideal world is not "real" (compared to your wall > clock) and has a slight jitter. > the jitter of [phasor~] is cleared by sending samples in a buffered > way to your soundcard. > with MIDI, Pd doesn't do any buffering and no synchronisation to some > external clock is done, so messages appear in bursts which you notice > as a inaccurate timing. > but the problem is really not Pd's internal timing (which is "ideal") > but the communication to the outside world. > > so to answer that specific question: [phasor~] will help you, but only > if you are able to use the signal that comes out of your soundcard, > which is synced to the wall clock, in order to trigger (or do whatever > you want to do). > if you only want to use audio-objects as an internal clock source, > then you will gain exactly nothing (but lose a lot, since you > complicate things which you normally get for free). > > >>> maybe simply change MIDI interface to without-driver model. >> yes, that sound like a good solution. > > well yes, if your midi driver is broken (that's how i interpret a > "weird stacking process"), you should probably replace that. > > fgmadr > IOhannes > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAlC0iYMACgkQkX2Xpv6ydvSnRwCgr46N5LhnlkpNtiBQUFx8BKbE > BMgAn3dpbvGMaDuoGWWH8shQqYZfoCO4 > =IhZR > -END PGP SIGNATURE- > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-11-26 23:29, Cyrille Henry wrote: > > > Le 26/11/2012 22:38, Jean-Marie Adrien a écrit : >> Thanks Miller ! >>> -nosound -udiobuf 5 -slepgrain 1 >> Definitely academic :) >> >> But I run intense audio on this PD instance, together with midi >> driving lights in real time. here are the flags : >> >> -rt -noadc -midioutdev 1,2 -audiooutdev 2 -outchannels 8 >> >> phasor~ would not do it ? > phasor~ will do provide a better clock than a metro since pd > internal time is "perfect". your problem come from jitter between > "pd time" and "real world time". just to clarify: both [phasor~] and [metro] live in an ideal world with perfect timing. unfortunately this ideal world is not "real" (compared to your wall clock) and has a slight jitter. the jitter of [phasor~] is cleared by sending samples in a buffered way to your soundcard. with MIDI, Pd doesn't do any buffering and no synchronisation to some external clock is done, so messages appear in bursts which you notice as a inaccurate timing. but the problem is really not Pd's internal timing (which is "ideal") but the communication to the outside world. so to answer that specific question: [phasor~] will help you, but only if you are able to use the signal that comes out of your soundcard, which is synced to the wall clock, in order to trigger (or do whatever you want to do). if you only want to use audio-objects as an internal clock source, then you will gain exactly nothing (but lose a lot, since you complicate things which you normally get for free). >> maybe simply change MIDI interface to without-driver model. > yes, that sound like a good solution. well yes, if your midi driver is broken (that's how i interpret a "weird stacking process"), you should probably replace that. fgmadr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlC0iYMACgkQkX2Xpv6ydvSnRwCgr46N5LhnlkpNtiBQUFx8BKbE BMgAn3dpbvGMaDuoGWWH8shQqYZfoCO4 =IhZR -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Freezes with Pd-Extended and Jack
On Die, 2012-11-27 at 10:20 +0100, Roman Haefeli wrote: > The problem seems related to the fact that switching DSP also switches > the jack client on and off. I think the preferred way would be to be > able to switch DSP on/off independently from switching audio back-end > on/off. I just tested pd-l2ork and it seems this is exactly how it fixes the freeze problem: Turning DSP off does not kill the pd client in jack. Roman > On Mit, 2012-11-21 at 20:35 -0200, Esteban Viveros wrote: > > Hello, > > > > > > I'm using pd-extended 0.43.4, installed via Hans-Cristoph Steiner ppa. > > I'm using this version because I can't install the stable version in > > Ubuntu 12.04. > > > > > > The problem is, when I start pd with Jack in -rt mode or wherever > > mode, if I turn on dsp, they work well, but if I turn off, and try to > > turn on yet dsp, pd-extended freeze... > > > > Closing Qjackctl (after some time ubuntu can close that) > > pd-extended returns to work, and I can use on alsa directly > > sucessfull.. > > > > > > Someone knows where I can comunicate this bug to the developers? Is > > here the place? > > > > > > Thanks a lot! > > > > > > -- > > > > > > Esteban Viveros > > > > (27) 8815 7170 > > (27) 3066 0359 > > (11) 95761 4125 > > (11) 2738 7868 > > > > www.bandpage.com/estebanviveros > > > > https://www.facebook.com/estebanviveros.art > > > > http://www.papodecompositor-es.blogspot.com.br/ > > > > http://expurgacao.art.br/ > > > > > > > > ___ > > Pd-list@iem.at mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] turn off object bar in pd-extended 0.43
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-11-26 22:33, András Murányi wrote: > It's me who maintains it (BTW don't send bugs to the bug tracker as > the plugin is not part of the distro). the bug-tracker has nothing todo with a "distro" (neither Pd-vanilla, nor Pd-extended) it's a service of sourceforge used by the pd community to track bugs, hence i used it (and because the project page didn't mention another place where i could report it). if you want bug-reports to go somewhere else, you could add an address for issues to [1] (and well, yes, i could have used the "contact address"...) fgmasdr IOhannes [1] http://puredata.info/downloads/plugins-plugin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlC0hjgACgkQkX2Xpv6ydvSEHQCfWgJVq7yZ7s0gajIXBAVGaCT2 EFUAoOXpsAP6aHW+6QpcRdgsImUjNxON =wqgR -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Freezes with Pd-Extended and Jack
Hi all Johnny-come-lately I am . . . I've experienced this problem since 0.43 (vanilla and extended), I believe, but I haven't really investigated it, because it didn't happen that often and I wasn't able to reliably reproduce it. Now I figured out a way to reliably reproduce it. It seems the likeliness is related to jackd's latency settings. The shorter the latency, the likelier is pd going to freeze. With a setting of 128 frames/period and 2 periods/buffer, I can reliably freeze pd by turning DSP off and on. The problem seems related to the fact that switching DSP also switches the jack client on and off. I think the preferred way would be to be able to switch DSP on/off independently from switching audio back-end on/off. @Miller Are you still planning to seperate dsp switching from audio backe-end switching for 0.44? Roman On Mit, 2012-11-21 at 20:35 -0200, Esteban Viveros wrote: > Hello, > > > I'm using pd-extended 0.43.4, installed via Hans-Cristoph Steiner ppa. > I'm using this version because I can't install the stable version in > Ubuntu 12.04. > > > The problem is, when I start pd with Jack in -rt mode or wherever > mode, if I turn on dsp, they work well, but if I turn off, and try to > turn on yet dsp, pd-extended freeze... > > Closing Qjackctl (after some time ubuntu can close that) > pd-extended returns to work, and I can use on alsa directly > sucessfull.. > > > Someone knows where I can comunicate this bug to the developers? Is > here the place? > > > Thanks a lot! > > > -- > > > Esteban Viveros > > (27) 8815 7170 > (27) 3066 0359 > (11) 95761 4125 > (11) 2738 7868 > > www.bandpage.com/estebanviveros > > https://www.facebook.com/estebanviveros.art > > http://www.papodecompositor-es.blogspot.com.br/ > > http://expurgacao.art.br/ > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] 2 color questions in GEM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-11-27 04:47, chris clepper wrote: > The color values should probably be between 0.0 and 1.0 in floating > point. Try 1.0 0.65 0.0 > > Also, use [text3d] instead of 2d. and [color] is the object the change the color of an object. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlC0hNEACgkQkX2Xpv6ydvSUsACgypgL42YV2qQs88JtVobat1Id ABwAoPE+kOG92ABPUUyImewaqiZGNfe8 =D7bh -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
