Hi all,
Pd version 0.46-0test1 is available on http://msp.ucsd.edu/software.htm or via git from sourceforge: git clone git://git.code.sf.net/p/pure-data/pure-data cd pure-data git checkout
The 64-bit Mac compile isn't up yet, but the "usual" Mac, PC, and source packages are there.
Main new features: multiple instancing for libpd audio/MIDI device settings stored by name, not number netsend/netreceive can be used bidirectionally [list tosymbol] and [list fromsymbol] for string handling Jack enabled in compiled Mac version lots of small bug fixes
cheers Miller
Pd-announce mailing list Pd-announce@lists.iem.at http://lists.puredata.info/listinfo/pd-announce
Does this mean that libpd could now be embedded in vst (etc) plugins and work with multiple instances?
Oli
On Friday, August 15, 2014, Miller Puckette msp@ucsd.edu wrote:
Hi all,
Pd version 0.46-0test1 is available on http://msp.ucsd.edu/software.htm or via git from sourceforge: git clone git://git.code.sf.net/p/pure-data/pure-data cd pure-data git checkout
The 64-bit Mac compile isn't up yet, but the "usual" Mac, PC, and source packages are there.
Main new features: multiple instancing for libpd audio/MIDI device settings stored by name, not number netsend/netreceive can be used bidirectionally [list tosymbol] and [list fromsymbol] for string handling Jack enabled in compiled Mac version lots of small bug fixes
cheers Miller
Pd-announce mailing list Pd-announce@lists.iem.at javascript:; http://lists.puredata.info/listinfo/pd-announce _______________________________________________ Pd-list@lists.iem.at javascript:; mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
That's the intention. It will take an update to libpd (to import the new PD source and make a couple of small changes) - I think they'll wait until the final 0.46-0 before they do all the updating.
I tested this on my own, making the needed changes to libpd and writing a test program to host two Pds - seems to work. But who knows what will come up when people start testing it more extensively.
cheers M
On Fri, Aug 15, 2014 at 11:03:52PM +0100, Oliver Larkin wrote:
Does this mean that libpd could now be embedded in vst (etc) plugins and work with multiple instances?
Oli
On Friday, August 15, 2014, Miller Puckette msp@ucsd.edu wrote:
Hi all,
Pd version 0.46-0test1 is available on http://msp.ucsd.edu/software.htm or via git from sourceforge: git clone git://git.code.sf.net/p/pure-data/pure-data cd pure-data git checkout
The 64-bit Mac compile isn't up yet, but the "usual" Mac, PC, and source packages are there.
Main new features: multiple instancing for libpd audio/MIDI device settings stored by name, not number netsend/netreceive can be used bidirectionally [list tosymbol] and [list fromsymbol] for string handling Jack enabled in compiled Mac version lots of small bug fixes
cheers Miller
Pd-announce mailing list Pd-announce@lists.iem.at javascript:; http://lists.puredata.info/listinfo/pd-announce _______________________________________________ Pd-list@lists.iem.at javascript:; mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
awesome. still havent, played with the text object . played a live performance with no glitching on tasty tahir or whatever and the version that comes with that plus an in-un-stalled extended for the iem filters and such for 64 bit easy.
On Fri, Aug 15, 2014 at 7:11 PM, Miller Puckette msp@ucsd.edu wrote:
That's the intention. It will take an update to libpd (to import the new PD source and make a couple of small changes) - I think they'll wait until the final 0.46-0 before they do all the updating.
I tested this on my own, making the needed changes to libpd and writing a test program to host two Pds - seems to work. But who knows what will come up when people start testing it more extensively.
cheers M
On Fri, Aug 15, 2014 at 11:03:52PM +0100, Oliver Larkin wrote:
Does this mean that libpd could now be embedded in vst (etc) plugins and work with multiple instances?
Oli
On Friday, August 15, 2014, Miller Puckette msp@ucsd.edu wrote:
Hi all,
Pd version 0.46-0test1 is available on
http://msp.ucsd.edu/software.htm
or via git from sourceforge: git clone git://git.code.sf.net/p/pure-data/pure-data cd pure-data git checkout
The 64-bit Mac compile isn't up yet, but the "usual" Mac, PC, and
source
packages are there.
Main new features: multiple instancing for libpd audio/MIDI device settings stored by name, not number netsend/netreceive can be used bidirectionally [list tosymbol] and [list fromsymbol] for string handling Jack enabled in compiled Mac version lots of small bug fixes
cheers Miller
Pd-announce mailing list Pd-announce@lists.iem.at javascript:; http://lists.puredata.info/listinfo/pd-announce _______________________________________________ Pd-list@lists.iem.at javascript:; mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello,
Would you kindly take a look at this libpd-related thread? http://createdigitalnoise.com/discussion/32693/ios-is-it-possible-to-impleme...
Just thought maybe the workaround discussed in there could be embedded into a new version of Pd/libpd
Best regards, Bektur
On Aug 16, 2014, at 5:11 AM, Miller Puckette msp@ucsd.edu wrote:
That's the intention. It will take an update to libpd (to import the new PD source and make a couple of small changes) - I think they'll wait until the final 0.46-0 before they do all the updating.
I tested this on my own, making the needed changes to libpd and writing a test program to host two Pds - seems to work. But who knows what will come up when people start testing it more extensively.
cheers M
On Fri, Aug 15, 2014 at 11:03:52PM +0100, Oliver Larkin wrote:
Does this mean that libpd could now be embedded in vst (etc) plugins and work with multiple instances?
Oli
On Friday, August 15, 2014, Miller Puckette msp@ucsd.edu wrote:
Hi all,
Pd version 0.46-0test1 is available on http://msp.ucsd.edu/software.htm or via git from sourceforge: git clone git://git.code.sf.net/p/pure-data/pure-data cd pure-data git checkout
The 64-bit Mac compile isn't up yet, but the "usual" Mac, PC, and source packages are there.
Main new features: multiple instancing for libpd audio/MIDI device settings stored by name, not number netsend/netreceive can be used bidirectionally [list tosymbol] and [list fromsymbol] for string handling Jack enabled in compiled Mac version lots of small bug fixes
cheers Miller
Pd-announce mailing list Pd-announce@lists.iem.at javascript:; http://lists.puredata.info/listinfo/pd-announce _______________________________________________ Pd-list@lists.iem.at javascript:; mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi!
On 16/08/14 07:18, Bektur wrote:
Would you kindly take a look at this libpd-related thread? http://createdigitalnoise.com/discussion/32693/ios-is-it-possible-to-impleme...
Just thought maybe the workaround discussed in there could be embedded into a new version of Pd/libpd
That should be fixed in the latest version of libpd. Oops: I didn't know about the thread on createdigitalnoise and the previous fix by Thomas Grill so I had re-done it. Oh well. It certainly looks like the same bug to me.
Cheers,
Chris.
Hello,
That’s great to hear, thanks for letting me know!
I was afraid that it would mess up with compatibility in the long term, so this fix was somewhat critical for me.
Best regards, Bektur
On Aug 16, 2014, at 9:39 PM, Chris McCormick chris@mccormick.cx wrote:
Hi!
On 16/08/14 07:18, Bektur wrote:
Would you kindly take a look at this libpd-related thread? http://createdigitalnoise.com/discussion/32693/ios-is-it-possible-to-impleme...
Just thought maybe the workaround discussed in there could be embedded into a new version of Pd/libpd
That should be fixed in the latest version of libpd. Oops: I didn't know about the thread on createdigitalnoise and the previous fix by Thomas Grill so I had re-done it. Oh well. It certainly looks like the same bug to me.
Cheers,
Chris.
hi there, I see you updated vcf's help file, cool
But when you say, "These may be used as bandpass and lowpass filter outputs" you mean both outputs, right? Not that the first is a bandpass and the second a lowpass, huh?
cheers
2014-08-16 14:04 GMT-03:00 Bektur ph318@yandex.ru:
Hello,
That’s great to hear, thanks for letting me know!
I was afraid that it would mess up with compatibility in the long term, so this fix was somewhat critical for me.
Best regards, Bektur
On Aug 16, 2014, at 9:39 PM, Chris McCormick chris@mccormick.cx wrote:
Hi!
On 16/08/14 07:18, Bektur wrote:
Would you kindly take a look at this libpd-related thread?
http://createdigitalnoise.com/discussion/32693/ios-is-it-possible-to-impleme...
Just thought maybe the workaround discussed in there could be embedded into a new version of Pd/libpd
That should be fixed in the latest version of libpd. Oops: I didn't know about the thread on createdigitalnoise and the previous fix by Thomas Grill so I had re-done it. Oh well. It certainly looks like the same bug to me.
Cheers,
Chris.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
audio/MIDI device settings stored by name, not number
hmm, what does that mean in pratical terms? I'm struggling to get it.
cheers
2014-08-17 18:59 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
hi there, I see you updated vcf's help file, cool
But when you say, "These may be used as bandpass and lowpass filter outputs" you mean both outputs, right? Not that the first is a bandpass and the second a lowpass, huh?
cheers
2014-08-16 14:04 GMT-03:00 Bektur ph318@yandex.ru:
Hello,
That’s great to hear, thanks for letting me know!
I was afraid that it would mess up with compatibility in the long term, so this fix was somewhat critical for me.
Best regards, Bektur
On Aug 16, 2014, at 9:39 PM, Chris McCormick chris@mccormick.cx wrote:
Hi!
On 16/08/14 07:18, Bektur wrote:
Would you kindly take a look at this libpd-related thread?
http://createdigitalnoise.com/discussion/32693/ios-is-it-possible-to-impleme...
Just thought maybe the workaround discussed in there could be embedded into a new version of Pd/libpd
That should be fixed in the latest version of libpd. Oops: I didn't know about the thread on createdigitalnoise and the previous fix by Thomas Grill so I had re-done it. Oh well. It certainly looks like the same bug to me.
Cheers,
Chris.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
seems like they're actually resonant lowpass filters that can be used as bandpass for high Q values, right?
2014-08-17 18:59 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
hi there, I see you updated vcf's help file, cool
But when you say, "These may be used as bandpass and lowpass filter outputs" you mean both outputs, right? Not that the first is a bandpass and the second a lowpass, huh?
cheers
2014-08-16 14:04 GMT-03:00 Bektur ph318@yandex.ru:
Hello,
That’s great to hear, thanks for letting me know!
I was afraid that it would mess up with compatibility in the long term, so this fix was somewhat critical for me.
Best regards, Bektur
On Aug 16, 2014, at 9:39 PM, Chris McCormick chris@mccormick.cx wrote:
Hi!
On 16/08/14 07:18, Bektur wrote:
Would you kindly take a look at this libpd-related thread?
http://createdigitalnoise.com/discussion/32693/ios-is-it-possible-to-impleme...
Just thought maybe the workaround discussed in there could be embedded into a new version of Pd/libpd
That should be fixed in the latest version of libpd. Oops: I didn't know about the thread on createdigitalnoise and the previous fix by Thomas Grill so I had re-done it. Oh well. It certainly looks like the same bug to me.
Cheers,
Chris.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
at least I see that's what [bp~] actually is
2014-08-17 19:28 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
seems like they're actually resonant lowpass filters that can be used as bandpass for high Q values, right?
2014-08-17 18:59 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
hi there, I see you updated vcf's help file, cool
But when you say, "These may be used as bandpass and lowpass filter outputs" you mean both outputs, right? Not that the first is a bandpass and the second a lowpass, huh?
cheers
2014-08-16 14:04 GMT-03:00 Bektur ph318@yandex.ru:
Hello,
That’s great to hear, thanks for letting me know!
I was afraid that it would mess up with compatibility in the long term, so this fix was somewhat critical for me.
Best regards, Bektur
On Aug 16, 2014, at 9:39 PM, Chris McCormick chris@mccormick.cx wrote:
Hi!
On 16/08/14 07:18, Bektur wrote:
Would you kindly take a look at this libpd-related thread?
http://createdigitalnoise.com/discussion/32693/ios-is-it-possible-to-impleme...
Just thought maybe the workaround discussed in there could be embedded into a new version of Pd/libpd
That should be fixed in the latest version of libpd. Oops: I didn't
know
about the thread on createdigitalnoise and the previous fix by Thomas Grill so I had re-done it. Oh well. It certainly looks like the same
bug
to me.
Cheers,
Chris.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Miller,
On 16/08/14 01:11, Miller Puckette wrote:
That's the intention. It will take an update to libpd (to import the new PD source and make a couple of small changes) - I think they'll wait until the final 0.46-0 before they do all the updating.
I tested this on my own, making the needed changes to libpd and writing a test program to host two Pds - seems to work. But who knows what will come up when people start testing it more extensively.
If you have any code, or a git branch, or gotchas to share in this regard that would be awesome!
Cheers,
Chris.
It's not complete (I didn't deal with MIDI and determining $0 correctly, as others pointed out) but my original changes and test program are here:
http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html
(see further in that thread for more ideas and details.)
cheers M
On Sat, Aug 16, 2014 at 05:41:10PM +0200, Chris McCormick wrote:
Hi Miller,
On 16/08/14 01:11, Miller Puckette wrote:
That's the intention. It will take an update to libpd (to import the new PD source and make a couple of small changes) - I think they'll wait until the final 0.46-0 before they do all the updating.
I tested this on my own, making the needed changes to libpd and writing a test program to host two Pds - seems to work. But who knows what will come up when people start testing it more extensively.
If you have any code, or a git branch, or gotchas to share in this regard that would be awesome!
Cheers,
Chris.
Hi Miller
Thanks for the new version. I'm especially excited about [list fromsymbol] and its sister.
Setting range for sliders - either through properties dialog or dynamically by message 'range X Y' - doesn't work anymore. The graphical width is automatically used as the upper bound. Also, sliders don't limit the incoming numbers anymore (though that might be intentional, I don't know).
I'm under the impression that you prefer to read reports here. If that is not the case, I'll file a proper ticket on the bug tracker.
Roman
On Don, 2014-08-14 at 21:38 -0700, Miller Puckette wrote:
Hi all,
Pd version 0.46-0test1 is available on http://msp.ucsd.edu/software.htm or via git from sourceforge: git clone git://git.code.sf.net/p/pure-data/pure-data cd pure-data git checkout
The 64-bit Mac compile isn't up yet, but the "usual" Mac, PC, and source packages are there.
Main new features: multiple instancing for libpd audio/MIDI device settings stored by name, not number netsend/netreceive can be used bidirectionally [list tosymbol] and [list fromsymbol] for string handling Jack enabled in compiled Mac version lots of small bug fixes
cheers Miller
Pd-announce mailing list Pd-announce@lists.iem.at http://lists.puredata.info/listinfo/pd-announce
Ouch! Thanks for flagging that. Major oops.
Yes, I see stuff on Pd list right away, but only go hunting through the bug reports when I have 'free' time.
M
On Mon, Aug 18, 2014 at 10:02:33PM +0200, Roman Haefeli wrote:
Hi Miller
Thanks for the new version. I'm especially excited about [list fromsymbol] and its sister.
Setting range for sliders - either through properties dialog or dynamically by message 'range X Y' - doesn't work anymore. The graphical width is automatically used as the upper bound. Also, sliders don't limit the incoming numbers anymore (though that might be intentional, I don't know).
I'm under the impression that you prefer to read reports here. If that is not the case, I'll file a proper ticket on the bug tracker.
Roman
On Don, 2014-08-14 at 21:38 -0700, Miller Puckette wrote:
Hi all,
Pd version 0.46-0test1 is available on http://msp.ucsd.edu/software.htm or via git from sourceforge: git clone git://git.code.sf.net/p/pure-data/pure-data cd pure-data git checkout
The 64-bit Mac compile isn't up yet, but the "usual" Mac, PC, and source packages are there.
Main new features: multiple instancing for libpd audio/MIDI device settings stored by name, not number netsend/netreceive can be used bidirectionally [list tosymbol] and [list fromsymbol] for string handling Jack enabled in compiled Mac version lots of small bug fixes
cheers Miller
Pd-announce mailing list Pd-announce@lists.iem.at http://lists.puredata.info/listinfo/pd-announce
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
OK... test2 is up - try that.
thanks M
On Mon, Aug 18, 2014 at 02:51:10PM -0700, Miller Puckette wrote:
Ouch! Thanks for flagging that. Major oops.
Yes, I see stuff on Pd list right away, but only go hunting through the bug reports when I have 'free' time.
M
On Mon, Aug 18, 2014 at 10:02:33PM +0200, Roman Haefeli wrote:
Hi Miller
Thanks for the new version. I'm especially excited about [list fromsymbol] and its sister.
Setting range for sliders - either through properties dialog or dynamically by message 'range X Y' - doesn't work anymore. The graphical width is automatically used as the upper bound. Also, sliders don't limit the incoming numbers anymore (though that might be intentional, I don't know).
I'm under the impression that you prefer to read reports here. If that is not the case, I'll file a proper ticket on the bug tracker.
Roman
On Don, 2014-08-14 at 21:38 -0700, Miller Puckette wrote:
Hi all,
Pd version 0.46-0test1 is available on http://msp.ucsd.edu/software.htm or via git from sourceforge: git clone git://git.code.sf.net/p/pure-data/pure-data cd pure-data git checkout
The 64-bit Mac compile isn't up yet, but the "usual" Mac, PC, and source packages are there.
Main new features: multiple instancing for libpd audio/MIDI device settings stored by name, not number netsend/netreceive can be used bidirectionally [list tosymbol] and [list fromsymbol] for string handling Jack enabled in compiled Mac version lots of small bug fixes
cheers Miller
Pd-announce mailing list Pd-announce@lists.iem.at http://lists.puredata.info/listinfo/pd-announce
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 2014-08-18 at 16:56 -0700, Miller Puckette wrote:
OK... test2 is up - try that.
I'm afraid it is still not quite right. The number that is sent right on mouse click still ignores the currently set range. Only the subsequent numbers during dragging are scaled correctly.
Steps to reproduce:
- Create slider
- Set range to 0, 1
- Set the slider to a non-zero value
- Click on the slider
You get something like '45' (depending on the slider position), though the value should be something in between 0 and 1.
Roman
On Mon, Aug 18, 2014 at 02:51:10PM -0700, Miller Puckette wrote:
Ouch! Thanks for flagging that. Major oops.
Yes, I see stuff on Pd list right away, but only go hunting through the bug reports when I have 'free' time.
M
On Mon, Aug 18, 2014 at 10:02:33PM +0200, Roman Haefeli wrote:
Hi Miller
Thanks for the new version. I'm especially excited about [list fromsymbol] and its sister.
Setting range for sliders - either through properties dialog or dynamically by message 'range X Y' - doesn't work anymore. The graphical width is automatically used as the upper bound. Also, sliders don't limit the incoming numbers anymore (though that might be intentional, I don't know).
I'm under the impression that you prefer to read reports here. If that is not the case, I'll file a proper ticket on the bug tracker.
Roman
On Don, 2014-08-14 at 21:38 -0700, Miller Puckette wrote:
Hi all,
Pd version 0.46-0test1 is available on http://msp.ucsd.edu/software.htm or via git from sourceforge: git clone git://git.code.sf.net/p/pure-data/pure-data cd pure-data git checkout
The 64-bit Mac compile isn't up yet, but the "usual" Mac, PC, and source packages are there.
Main new features: multiple instancing for libpd audio/MIDI device settings stored by name, not number netsend/netreceive can be used bidirectionally [list tosymbol] and [list fromsymbol] for string handling Jack enabled in compiled Mac version lots of small bug fixes
cheers Miller
Pd-announce mailing list Pd-announce@lists.iem.at http://lists.puredata.info/listinfo/pd-announce
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Sure enough - I missed a spot. I just fixed it again and put out test3.
thanks Miller
On Tue, Aug 19, 2014 at 10:52:06AM +0200, Roman Haefeli wrote:
On Mon, 2014-08-18 at 16:56 -0700, Miller Puckette wrote:
OK... test2 is up - try that.
I'm afraid it is still not quite right. The number that is sent right on mouse click still ignores the currently set range. Only the subsequent numbers during dragging are scaled correctly.
Steps to reproduce:
- Create slider
- Set range to 0, 1
- Set the slider to a non-zero value
- Click on the slider
You get something like '45' (depending on the slider position), though the value should be something in between 0 and 1.
Roman
On Mon, Aug 18, 2014 at 02:51:10PM -0700, Miller Puckette wrote:
Ouch! Thanks for flagging that. Major oops.
Yes, I see stuff on Pd list right away, but only go hunting through the bug reports when I have 'free' time.
M
On Mon, Aug 18, 2014 at 10:02:33PM +0200, Roman Haefeli wrote:
Hi Miller
Thanks for the new version. I'm especially excited about [list fromsymbol] and its sister.
Setting range for sliders - either through properties dialog or dynamically by message 'range X Y' - doesn't work anymore. The graphical width is automatically used as the upper bound. Also, sliders don't limit the incoming numbers anymore (though that might be intentional, I don't know).
I'm under the impression that you prefer to read reports here. If that is not the case, I'll file a proper ticket on the bug tracker.
Roman
On Don, 2014-08-14 at 21:38 -0700, Miller Puckette wrote:
Hi all,
Pd version 0.46-0test1 is available on http://msp.ucsd.edu/software.htm or via git from sourceforge: git clone git://git.code.sf.net/p/pure-data/pure-data cd pure-data git checkout
The 64-bit Mac compile isn't up yet, but the "usual" Mac, PC, and source packages are there.
Main new features: multiple instancing for libpd audio/MIDI device settings stored by name, not number netsend/netreceive can be used bidirectionally [list tosymbol] and [list fromsymbol] for string handling Jack enabled in compiled Mac version lots of small bug fixes
cheers Miller
Pd-announce mailing list Pd-announce@lists.iem.at http://lists.puredata.info/listinfo/pd-announce
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Die, 2014-08-19 at 10:42 -0700, Miller Puckette wrote:
Sure enough - I missed a spot. I just fixed it again and put out test3.
Did you push to git? The most recent commit I see in 'git log' is from 2014-08-18. I assume the test3 changes are more recent.
Anyway, I'll grab the source.tar.gz from your site.
Roman
On Tue, Aug 19, 2014 at 10:52:06AM +0200, Roman Haefeli wrote:
On Mon, 2014-08-18 at 16:56 -0700, Miller Puckette wrote:
OK... test2 is up - try that.
I'm afraid it is still not quite right. The number that is sent right on mouse click still ignores the currently set range. Only the subsequent numbers during dragging are scaled correctly.
Steps to reproduce:
- Create slider
- Set range to 0, 1
- Set the slider to a non-zero value
- Click on the slider
You get something like '45' (depending on the slider position), though the value should be something in between 0 and 1.
Roman
On Mon, Aug 18, 2014 at 02:51:10PM -0700, Miller Puckette wrote:
Ouch! Thanks for flagging that. Major oops.
Yes, I see stuff on Pd list right away, but only go hunting through the bug reports when I have 'free' time.
M
On Mon, Aug 18, 2014 at 10:02:33PM +0200, Roman Haefeli wrote:
Hi Miller
Thanks for the new version. I'm especially excited about [list fromsymbol] and its sister.
Setting range for sliders - either through properties dialog or dynamically by message 'range X Y' - doesn't work anymore. The graphical width is automatically used as the upper bound. Also, sliders don't limit the incoming numbers anymore (though that might be intentional, I don't know).
I'm under the impression that you prefer to read reports here. If that is not the case, I'll file a proper ticket on the bug tracker.
Roman
On Don, 2014-08-14 at 21:38 -0700, Miller Puckette wrote:
Hi all,
Pd version 0.46-0test1 is available on http://msp.ucsd.edu/software.htm or via git from sourceforge: git clone git://git.code.sf.net/p/pure-data/pure-data cd pure-data git checkout
The 64-bit Mac compile isn't up yet, but the "usual" Mac, PC, and source packages are there.
Main new features: multiple instancing for libpd audio/MIDI device settings stored by name, not number netsend/netreceive can be used bidirectionally [list tosymbol] and [list fromsymbol] for string handling Jack enabled in compiled Mac version lots of small bug fixes
cheers Miller
Pd-announce mailing list Pd-announce@lists.iem.at http://lists.puredata.info/listinfo/pd-announce
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mit, 2014-08-20 at 22:24 +0200, Roman Haefeli wrote:
On Die, 2014-08-19 at 10:42 -0700, Miller Puckette wrote:
Sure enough - I missed a spot. I just fixed it again and put out test3.
Did you push to git? The most recent commit I see in 'git log' is from 2014-08-18. I assume the test3 changes are more recent.
Anyway, I'll grab the source.tar.gz from your site.
Looks good for me now. Thanks for the quick fix.
Roman
Thanks - I must have forgotten to 'git push' - am doing that now.
M
On Wed, Aug 20, 2014 at 10:24:59PM +0200, Roman Haefeli wrote:
On Die, 2014-08-19 at 10:42 -0700, Miller Puckette wrote:
Sure enough - I missed a spot. I just fixed it again and put out test3.
Did you push to git? The most recent commit I see in 'git log' is from 2014-08-18. I assume the test3 changes are more recent.
Anyway, I'll grab the source.tar.gz from your site.
Roman
On Tue, Aug 19, 2014 at 10:52:06AM +0200, Roman Haefeli wrote:
On Mon, 2014-08-18 at 16:56 -0700, Miller Puckette wrote:
OK... test2 is up - try that.
I'm afraid it is still not quite right. The number that is sent right on mouse click still ignores the currently set range. Only the subsequent numbers during dragging are scaled correctly.
Steps to reproduce:
- Create slider
- Set range to 0, 1
- Set the slider to a non-zero value
- Click on the slider
You get something like '45' (depending on the slider position), though the value should be something in between 0 and 1.
Roman
On Mon, Aug 18, 2014 at 02:51:10PM -0700, Miller Puckette wrote:
Ouch! Thanks for flagging that. Major oops.
Yes, I see stuff on Pd list right away, but only go hunting through the bug reports when I have 'free' time.
M
On Mon, Aug 18, 2014 at 10:02:33PM +0200, Roman Haefeli wrote:
Hi Miller
Thanks for the new version. I'm especially excited about [list fromsymbol] and its sister.
Setting range for sliders - either through properties dialog or dynamically by message 'range X Y' - doesn't work anymore. The graphical width is automatically used as the upper bound. Also, sliders don't limit the incoming numbers anymore (though that might be intentional, I don't know).
I'm under the impression that you prefer to read reports here. If that is not the case, I'll file a proper ticket on the bug tracker.
Roman
On Don, 2014-08-14 at 21:38 -0700, Miller Puckette wrote: > Hi all, > > Pd version 0.46-0test1 is available on http://msp.ucsd.edu/software.htm > or via git from sourceforge: > git clone git://git.code.sf.net/p/pure-data/pure-data > cd pure-data > git checkout > > The 64-bit Mac compile isn't up yet, but the "usual" Mac, PC, and source > packages are there. > > Main new features: > multiple instancing for libpd > audio/MIDI device settings stored by name, not number > netsend/netreceive can be used bidirectionally > [list tosymbol] and [list fromsymbol] for string handling > Jack enabled in compiled Mac version > lots of small bug fixes > > cheers > Miller > > _______________________________________________ > Pd-announce mailing list > Pd-announce@lists.iem.at > http://lists.puredata.info/listinfo/pd-announce
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Miller,
On 20/08/14 22:33, Miller Puckette wrote:
Thanks - I must have forgotten to 'git push' - am doing that now.
I am still not seeing your changes. Maybe your git remote "origin" is pointing somewhere other than sourceforge or you are on a different branch than master?
Cheers,
Chris.
On Thu, 2014-08-21 at 11:30 +0200, Chris McCormick wrote:
Hi Miller,
On 20/08/14 22:33, Miller Puckette wrote:
Thanks - I must have forgotten to 'git push' - am doing that now.
I am still not seeing your changes. Maybe your git remote "origin" is pointing somewhere other than sourceforge or you are on a different branch than master?
Looks good to me. The most recent commit is:
commit 484619fff420213424f7b5d7994804d81b24ed86 Author: Miller Puckette msp@ucsd.edu Date: Wed Aug 20 21:51:04 2014 -0700
oscformat and oscparse objects. Should never have introduced these between
a test and a final release but couldn't help myself.
Roman
On Thu, 2014-08-21 at 12:29 +0200, Roman Haefeli wrote:
On Thu, 2014-08-21 at 11:30 +0200, Chris McCormick wrote:
Hi Miller,
On 20/08/14 22:33, Miller Puckette wrote:
Thanks - I must have forgotten to 'git push' - am doing that now.
I am still not seeing your changes. Maybe your git remote "origin" is pointing somewhere other than sourceforge or you are on a different branch than master?
Looks good to me. The most recent commit is:
commit 484619fff420213424f7b5d7994804d81b24ed86 Author: Miller Puckette msp@ucsd.edu Date: Wed Aug 20 21:51:04 2014 -0700
oscformat and oscparse objects. Should never have introduced these between a test and a final release but couldn't help myself.
I couldn't help myself having a quick glance at those newly introduced classes. It's definitely exciting to have OSC support in vanilla Pd.
I wondered about [oscparse] how address and payload can be distinguished after being parsed, since [oscparse] outputs all in one list.
Example: osc('/bla/bla 12') and osc('/bla bla 12') both are parsed to 'bla bla 12'.
Roman
I couldn't help myself having a quick glance at those newly introduced classes. It's definitely exciting to have OSC support in vanilla Pd.
I wondered about [oscparse] how address and payload can be distinguished after being parsed, since [oscparse] outputs all in one list.
Example: osc('/bla/bla 12') and osc('/bla bla 12') both are parsed to 'bla bla 12'.
Roman
Correct. The bet I'm making is that nobody who's receiving OSC messages would have any doubt which is it. YOu have to know what messages the source is sending you and what to do with them anyway. And if any source is actually sending "bla 12" to "/bla" and also "12" to /bla/bla, well, I think they're nuts, and anyway you can always grab the ones from mrpeach.
OTOH, if it does turn out that there's any real situation when such disamiguation is needed (for instance, storing OSC streams for later sequencing?) the objects could easily be altered to put in symbolic markers to separate everything - this would be in the form of a creation flag to make it an option. But I think for 99% of the use cases this would just be a huge extra pain.
There are similar limitations in the MIDI implementation that have been in place for years: you can't get note-off velocities (they're mapped to zero-velocity note-ons).
cheers Miller
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 21/08/2014 17:22, Miller Puckette a écrit :
There are similar limitations in the MIDI implementation that have been in place for years: you can't get note-off velocities (they're mapped to zero-velocity note-ons).
most hardware send note-on with 0 velocity as a note-off. that's not a problem of the midi implementation, but in midi specification.
cheers c
cheers Miller
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Correct - but if some keyboard actually sent a note-off message with a nonzero velocity a Pd patch wouldn't easily be able to get that value. I don't think it's important at all (and neither do I think the limitations in oscparse will ever matter) - but of course I could be wrong, since my experience with osc is smaller than tiny. I've never used the protocol at all. (I think FUDI is much cleaner :)
M
On Thu, Aug 21, 2014 at 05:42:42PM +0200, Cyrille Henry wrote:
Le 21/08/2014 17:22, Miller Puckette a écrit :
There are similar limitations in the MIDI implementation that have been in place for years: you can't get note-off velocities (they're mapped to zero-velocity note-ons).
most hardware send note-on with 0 velocity as a note-off. that's not a problem of the midi implementation, but in midi specification.
cheers c
cheers Miller
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 21/08/2014 17:47, Miller Puckette a écrit :
Correct - but if some keyboard actually sent a note-off message with a nonzero velocity a Pd patch wouldn't easily be able to get that value. I don't think it's important at all (and neither do I think the limitations in oscparse will ever matter) - but of course I could be wrong, since my experience with osc is smaller than tiny. I've never used the protocol at all. (I think FUDI is much cleaner :)
yes, i prefer fudi to. but on small hardware, like the one i was developing 12 years ago, OSC was faster. not because of the reduced bandwidth, but because of the conversion between ascii character to float. but that time is over now, and this conversion should be quicker even on "small" hardware.
cheers c
M
On Thu, Aug 21, 2014 at 05:42:42PM +0200, Cyrille Henry wrote:
Le 21/08/2014 17:22, Miller Puckette a écrit :
There are similar limitations in the MIDI implementation that have been in place for years: you can't get note-off velocities (they're mapped to zero-velocity note-ons).
most hardware send note-on with 0 velocity as a note-off. that's not a problem of the midi implementation, but in midi specification.
cheers c
cheers Miller
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, Aug 21, 2014 at 06:06:52PM +0200, Cyrille Henry wrote:
yes, i prefer fudi to. but on small hardware, like the one i was developing 12 years ago, OSC was faster. not because of the reduced bandwidth, but because of the conversion between ascii character to float. but that time is over now, and this conversion should be quicker even on "small" hardware.
cheers c
I agree - this is still a problem for pd~, which uses FUDI. I've been thinking for years about making a binary form of FUDI:
f <4 byte float> s <zero-terminated character string> ; ,
One thing I keep wondering is how, in netsend/netreceive, to name this so that it won't get confused with raw binary. Maybe it justneeds a name (BUDI?)
cheers M
Le 21/08/2014 18:42, Miller Puckette a écrit :
On Thu, Aug 21, 2014 at 06:06:52PM +0200, Cyrille Henry wrote:
yes, i prefer fudi to. but on small hardware, like the one i was developing 12 years ago, OSC was faster. not because of the reduced bandwidth, but because of the conversion between ascii character to float. but that time is over now, and this conversion should be quicker even on "small" hardware.
cheers c
I agree - this is still a problem for pd~, which uses FUDI. I've been thinking for years about making a binary form of FUDI:
f <4 byte float> s <zero-terminated character string> ; ,
yes, pd~ communication is very heavy : sending 8 different white noise to pd~ and sending them back to pd use more than 50% cpu on a decent computer. sending silence is much better, since their are less data to convert, but it's far from perfect. I think having no conversion at all will not be enough optimisation. That's why there is now a share memory external. for audio transfer : 1 synchronisation int is needed at every audio block and it add only 1 more block delay. since it's very efficient, the curent implementation of fudi in pd~ is no longer a problem for me.
cheers c
One thing I keep wondering is how, in netsend/netreceive, to name this so that it won't get confused with raw binary. Maybe it justneeds a name (BUDI?)
cheers M
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On August 21, 2014 05:42:42 PM Cyrille Henry wrote:
Le 21/08/2014 17:22, Miller Puckette a écrit :
There are similar limitations in the MIDI implementation that have been in place for years: you can't get note-off velocities (they're mapped to zero-velocity note-ons).
most hardware send note-on with 0 velocity as a note-off. that's not a problem of the midi implementation, but in midi specification.
Pardon my intrusion here.
Careful - most keyboards DO send true note-offs with release velocity values. Mine does and it's 30 years old. (Ensoniq ESQ-1).
Most receivers don't do anything useful with the values, depending on the selected patch, but they are sent nonetheless. Some users may want to do something funky with the values, particularly in a wide-ranging 'organic' app such as PD.
Tim. The MusE sequencer project.
cheers c
cheers Miller
Hi Miller,
Very cool, thanks for getting OSC objects into native Pd!
On 21/08/14 17:22, Miller Puckette wrote:
Correct. The bet I'm making is that nobody who's receiving OSC messages would have any doubt which is it. YOu have to know what messages the source is sending you and what to do with them anyway.
OTOH, if it does turn out that there's any real situation when such disamiguation is needed (for instance, storing OSC streams for later sequencing?) the objects could easily be altered to put in symbolic markers to separate everything - this would be in the form of a creation flag to make it an option. But I think for 99% of the use cases this would just be a huge extra pain.
I have attached a patch to oscparse giving it an extra outlet telling the user how many of the atoms belong to the address component. Let me know what you think or if I should take a different tack.
I feel like there are definitely going to be use-cases we can't think of requiring this information for the user (as well of the one you have already thought of).
Another good flag for the future might be one that leaves the address component the way it looks when it comes in so that people don't have to set up multiple routes if they are just listening for a single thing or two, what do you think?
Cheers,
Chris.
I think I'd want to disambiguate everything in one mechanism - perhaps interspersing the message itself with the information (putting the count in ahead of the address, and also putting symbols 'f', 'i', 's' and 'b' in front of the items). But I'm thinking it's wisest to wait and see what people need in real usage - if, indeed, anyone ever wants such disambiguation at all.
cheers M
On Fri, Aug 22, 2014 at 06:14:02PM +0200, Chris McCormick wrote:
Hi Miller,
Very cool, thanks for getting OSC objects into native Pd!
On 21/08/14 17:22, Miller Puckette wrote:
Correct. The bet I'm making is that nobody who's receiving OSC messages would have any doubt which is it. YOu have to know what messages the source is sending you and what to do with them anyway.
OTOH, if it does turn out that there's any real situation when such disamiguation is needed (for instance, storing OSC streams for later sequencing?) the objects could easily be altered to put in symbolic markers to separate everything - this would be in the form of a creation flag to make it an option. But I think for 99% of the use cases this would just be a huge extra pain.
I have attached a patch to oscparse giving it an extra outlet telling the user how many of the atoms belong to the address component. Let me know what you think or if I should take a different tack.
I feel like there are definitely going to be use-cases we can't think of requiring this information for the user (as well of the one you have already thought of).
Another good flag for the future might be one that leaves the address component the way it looks when it comes in so that people don't have to set up multiple routes if they are just listening for a single thing or two, what do you think?
Cheers,
Chris.
From 4bdcdea33c079f8b9ad5f15f4c665493c18f4b22 Mon Sep 17 00:00:00 2001 From: Chris McCormick chris@mccormick.cx Date: Fri, 22 Aug 2014 17:49:24 +0200 Subject: [PATCH] Added outlet to oscparse to indicate how many of the symbols belong to the address component of the incoming message.
doc/5.reference/oscparse-help.pd | 32 +++++++++++++++++--------------- src/x_misc.c | 11 ++++++++--- 2 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/doc/5.reference/oscparse-help.pd b/doc/5.reference/oscparse-help.pd index 42a4d3d..8b96aea 100644 --- a/doc/5.reference/oscparse-help.pd +++ b/doc/5.reference/oscparse-help.pd @@ -1,10 +1,10 @@ -#N canvas 5 71 705 636 12; +#N canvas 4 66 705 636 12; #X obj 170 492 oscparse; #X text 51 579 see also:; #X obj 139 579 oscformat; #X obj 223 579 netreceive; #X text 434 582 updated for Pd version 0.46; -#X obj 170 515 print parse-output; +#X obj 170 539 print parse-output; #X obj 313 579 list; #X obj 418 437 netreceive -u -b; #X msg 418 382 listen 5000; @@ -20,25 +20,27 @@ #X text 415 358 packets from network; #X text 520 382 slisten on port 5000; #X text 557 437 UDP packets , binary output, f 13; -#X text 45 41 oscparse take incoming lists of numbers , interpreting -them as the bytes in an OSC message. The output is a list containing -, first , the symbols making up the address of the OSC packet , -and following that , numbers and symbols as present in the OSC message. -OSC messages may contain 'float' , 'int' , 'string' , or 'blob' -elements. Blobs are arrays of bytes (numbers between 0 and 255) and -are copied to the output preceded by the blob's byte count.; #X text 80 11 oscparse - parse Open Sound Control (OSC) packets into Pd messages, f 67; -#X text 44 187 OSC is a complicated networking protocol (FUDI , as +#X obj 223 515 print address-count; +#X text 44 207 OSC is a complicated networking protocol (FUDI , as used in netsend/netreceive is simpler and better but less widely used). oscparse and oscformat make no attempt to deal with timetags or aggregates of packets , nor with streaming OSC. Also , 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. -; +to 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.; +#X text 45 41 oscparse take incoming lists of numbers , interpreting +them as the bytes in an OSC message. The left outlet yeilds a list +containing , first , the symbols making up the address of the OSC +packet , and following that , numbers and symbols as present in the +OSC message. The right outlet yeilds the number of elements comprising +the address portion of the incoming message. OSC messages may contain +'float' , 'int' , 'string' , or 'blob' elements. Blobs are arrays +of bytes (numbers between 0 and 255) and are copied to the output preceded +by the blob's byte count.; #X connect 0 0 5 0; +#X connect 0 1 22 0; #X connect 7 0 0 0; #X connect 8 0 7 0; #X connect 9 0 7 0; diff --git a/src/x_misc.c b/src/x_misc.c index 6fb48aa..ba805cc 100644 --- a/src/x_misc.c +++ b/src/x_misc.c @@ -328,6 +328,8 @@ static t_class *oscparse_class; typedef struct _oscparse { t_object x_obj;
- t_outlet *x_out1;
- t_outlet *x_out2;
} t_oscparse;
#define ROUNDUPTO4(x) (((x) + 3) & (~3)) @@ -361,7 +363,7 @@ static t_symbol *grabstring(int argc, t_atom *argv, int *ip, int slash)
static void oscparse_list(t_oscparse *x, t_symbol *s, int argc, t_atom *argv) {
- int i, j, j2, k, outc = 1, blob = 0, typeonset, dataonset, nfield;
- int i, j, j2, k, outc = 1, blob = 0, typeonset, dataonset, nfield, addresscount; t_atom *outv; if (!argc) return;
@@ -379,6 +381,7 @@ static void oscparse_list(t_oscparse *x, t_symbol *s, int argc, t_atom *argv) for (i = 1; i < argc && argv[i].a_w.w_float != 0; i++) if (argv[i].a_w.w_float == '/') outc++;
- addresscount = outc; i = ROUNDUPTO4(i+1); if (argv[i].a_w.w_float != ',' || (i+1) >= argc) {
@@ -472,7 +475,8 @@ static void oscparse_list(t_oscparse *x, t_symbol *s, int argc, t_atom *argv) (int)(argv[i].a_w.w_float), (int)(argv[i].a_w.w_float)); } }
- outlet_list(x->x_obj.ob_outlet, 0, j, outv);
- outlet_float(x->x_out2, (t_float)addresscount);
- outlet_list(x->x_out1, 0, j, outv); return;
tooshort: pd_error(x, "oscparse: OSC message ended prematurely"); @@ -481,7 +485,8 @@ tooshort: static t_oscparse *oscparse_new(t_symbol *s, int argc, t_atom *argv) { t_oscparse *x = (t_oscparse *)pd_new(oscparse_class);
- outlet_new(&x->x_obj, gensym("list"));
- x->x_out1 = outlet_new(&x->x_obj, &s_list);
- x->x_out2 = outlet_new(&x->x_obj, &s_float); return (x);
}
-- 1.7.10.4
Hi Miller,
On 22/08/14 23:08, Miller Puckette wrote:
I think I'd want to disambiguate everything in one mechanism - perhaps interspersing the message itself with the information (putting the count in ahead of the address, and also putting symbols 'f', 'i', 's' and 'b' in front of the items). But I'm thinking it's wisest to wait and see what people need in real usage - if, indeed, anyone ever wants such disambiguation at all.
Gotcha, and anyway it strikes me that the user can still get the number of address components already by counting the slash characters in the input, which is a trivial subpatch/abstraction.
Cheers,
Chris.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-08-22 23:08, Miller Puckette wrote:
I think I'd want to disambiguate everything in one mechanism - perhaps interspersing the message itself with the information (putting the count in ahead of the address, and also putting symbols 'f', 'i', 's' and 'b' in front of the items). But I'm thinking it's wisest to wait and see what people need in real usage
- if, indeed, anyone ever wants such disambiguation at all.
thanks for finally bringing OSC to Pd-vanilla.
while i understand the wish to keep those objects as simple as possible, i really think that at least [oscparse] should be able to deal with "#bundle"s.
many many OSC applications i came across, send there messages as bundles (mostly for timetagging reasons). even if we don't care about timetags (or rather: leave them to mrpeach), Pd should be able to make *some* use of them (that is: unwrap the bundle and spit out the messages contained therein).
fmasdr IOhannes
Yeah, I was thinking about whether to fool with bundles or not. It's a stupidly designed feature (they don't need to be hierarchical if all they serve for is to enforce simultanaety) but if lots of applications are generating them I guess oscparse should deal with them somehow. I'll look and see how ugly it would be to shoehorn it in.
M
On Mon, Aug 25, 2014 at 11:21:08AM +0200, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-08-22 23:08, Miller Puckette wrote:
I think I'd want to disambiguate everything in one mechanism - perhaps interspersing the message itself with the information (putting the count in ahead of the address, and also putting symbols 'f', 'i', 's' and 'b' in front of the items). But I'm thinking it's wisest to wait and see what people need in real usage
- if, indeed, anyone ever wants such disambiguation at all.
thanks for finally bringing OSC to Pd-vanilla.
while i understand the wish to keep those objects as simple as possible, i really think that at least [oscparse] should be able to deal with "#bundle"s.
many many OSC applications i came across, send there messages as bundles (mostly for timetagging reasons). even if we don't care about timetags (or rather: leave them to mrpeach), Pd should be able to make *some* use of them (that is: unwrap the bundle and spit out the messages contained therein).
fmasdr IOhannes
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQIcBAEBCAAGBQJT+wAAAAoJELZQGcR/ejb4h/0P/0HwdJP2e45vIU7lgDP8J060 LGWW6VLdX0TYuAZCOfHjRvtjj5rrMS6/ODvg71YbbuJ9R3jST1DUGsQ+TSp4ZR4L HgFr/NSCaeB4S7MHl1Fp4Zb2B1UTBSZHnKgAA93SIhZ0JeJiaHxEOksNvghMQsy5 dEeVw5++VYGwixUOubeyqK12KaWc74C9FvKccH/iijC0eQHRd77uu4deNXjlA8eM 0+nXVQYqok3WNUoTbCDzzCDPTHVEM8IqRG2NclgxPEM3aWomtVP8+RyMt4HPkctC LiNiCe+ZNBVJOsF0g8TtYQ91v/L80uVYNNkKrBakTGoYLCPlZq5FWkrVh97f0CXE 2+RCUGTV/4qSkfIEncZfBOcY35sTy/CxTwNFYjpUC0r3OoKrIgyciP4XuHTxDZTC NulyGrsHVjIxivJ9WEEJerVi09pQ0nikZy287a2oo5IFttgLnMiZNGMRVr5kVk2e Y2kFoeP+WvWame8lYi7l4VY3zi6Mqgfes47MlHVcmUAyJxd7CRjz/zoxPcuwXjy+ i69v0p23C0GhrQ3gINfjn9pfk8VHI23nkxmWanx/NSTSU1yitetJ687gL94CwDyM 6EoawIGFIIjy+pEnNFdLa169atxGFCCr6P0mfIz4CTKbakB35WaGKrN4uCKrgQZj IOYJTS0wEf8L37pHR2Z8 =rzk7 -----END PGP SIGNATURE-----
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
OK... oscparse should onw handle bundles. (OTOH I didn't try to do anything with the timetag - couldn't figure out a reasonable way to deal with it.)
cheers M
On Mon, Aug 25, 2014 at 09:08:28AM -0700, Miller Puckette wrote:
Yeah, I was thinking about whether to fool with bundles or not. It's a stupidly designed feature (they don't need to be hierarchical if all they serve for is to enforce simultanaety) but if lots of applications are generating them I guess oscparse should deal with them somehow. I'll look and see how ugly it would be to shoehorn it in.
M
On Mon, Aug 25, 2014 at 11:21:08AM +0200, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-08-22 23:08, Miller Puckette wrote:
I think I'd want to disambiguate everything in one mechanism - perhaps interspersing the message itself with the information (putting the count in ahead of the address, and also putting symbols 'f', 'i', 's' and 'b' in front of the items). But I'm thinking it's wisest to wait and see what people need in real usage
- if, indeed, anyone ever wants such disambiguation at all.
thanks for finally bringing OSC to Pd-vanilla.
while i understand the wish to keep those objects as simple as possible, i really think that at least [oscparse] should be able to deal with "#bundle"s.
many many OSC applications i came across, send there messages as bundles (mostly for timetagging reasons). even if we don't care about timetags (or rather: leave them to mrpeach), Pd should be able to make *some* use of them (that is: unwrap the bundle and spit out the messages contained therein).
fmasdr IOhannes
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQIcBAEBCAAGBQJT+wAAAAoJELZQGcR/ejb4h/0P/0HwdJP2e45vIU7lgDP8J060 LGWW6VLdX0TYuAZCOfHjRvtjj5rrMS6/ODvg71YbbuJ9R3jST1DUGsQ+TSp4ZR4L HgFr/NSCaeB4S7MHl1Fp4Zb2B1UTBSZHnKgAA93SIhZ0JeJiaHxEOksNvghMQsy5 dEeVw5++VYGwixUOubeyqK12KaWc74C9FvKccH/iijC0eQHRd77uu4deNXjlA8eM 0+nXVQYqok3WNUoTbCDzzCDPTHVEM8IqRG2NclgxPEM3aWomtVP8+RyMt4HPkctC LiNiCe+ZNBVJOsF0g8TtYQ91v/L80uVYNNkKrBakTGoYLCPlZq5FWkrVh97f0CXE 2+RCUGTV/4qSkfIEncZfBOcY35sTy/CxTwNFYjpUC0r3OoKrIgyciP4XuHTxDZTC NulyGrsHVjIxivJ9WEEJerVi09pQ0nikZy287a2oo5IFttgLnMiZNGMRVr5kVk2e Y2kFoeP+WvWame8lYi7l4VY3zi6Mqgfes47MlHVcmUAyJxd7CRjz/zoxPcuwXjy+ i69v0p23C0GhrQ3gINfjn9pfk8VHI23nkxmWanx/NSTSU1yitetJ687gL94CwDyM 6EoawIGFIIjy+pEnNFdLa169atxGFCCr6P0mfIz4CTKbakB35WaGKrN4uCKrgQZj IOYJTS0wEf8L37pHR2Z8 =rzk7 -----END PGP SIGNATURE-----
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 2014-08-21 at 11:30 +0200, Chris McCormick wrote:
oscformat and oscparse objects. Should never have introduced these
between
a test and a final release but couldn't help myself.
!!!
Yep, you are right, my mistake!
Cheers,
Chris.
On 19/08/14 19:42, Miller Puckette wrote:
Sure enough - I missed a spot. I just fixed it again and put out test3.
there seems to be a similar problem with sliders and init in test3: a slider with init enabled and saved in pd < .46 (.43 for example) is initialized with the pixel-height/width instead of the output-value. the same sliders output value saved in .46 is initialized correctly, but the position of the graphical representation is set to a wrong value.
Steps to reproduce:
- Create slider
- Set range to 0, 1
- Set the slider to a non-zero value
- Click on the slider
You get something like '45' (depending on the slider position), though the value should be something in between 0 and 1.
bis denn! martin
OK... hopefully foxed now. THanks as always for flagging it.
Test 4 is out on git and on http://msp.ucsd.edu/software.html
cheers Miller
On Sat, Aug 23, 2014 at 11:00:31AM +0200, martin brinkmann wrote:
On 19/08/14 19:42, Miller Puckette wrote:
Sure enough - I missed a spot. I just fixed it again and put out test3.
there seems to be a similar problem with sliders and init in test3: a slider with init enabled and saved in pd < .46 (.43 for example) is initialized with the pixel-height/width instead of the output-value. the same sliders output value saved in .46 is initialized correctly, but the position of the graphical representation is set to a wrong value.
Steps to reproduce:
- Create slider
- Set range to 0, 1
- Set the slider to a non-zero value
- Click on the slider
You get something like '45' (depending on the slider position), though the value should be something in between 0 and 1.
bis denn! martin
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 24/08/14 02:33, Miller Puckette wrote:
OK... hopefully foxed now. THanks as always for flagging it.
Test 4 is out on git and on http://msp.ucsd.edu/software.html
thanks, this looks right now.
but i get either a segfault or "double free or corruption (fasttop): 0x08ccbaf8 **" when using [pipe], for example the pipe-help patch.
bis denn! martin
same here. cheers c
Le 25/08/2014 16:38, martin brinkmann a écrit :
On 24/08/14 02:33, Miller Puckette wrote:
OK... hopefully foxed now. THanks as always for flagging it.
Test 4 is out on git and on http://msp.ucsd.edu/software.html
thanks, this looks right now.
but i get either a segfault or "double free or corruption (fasttop): 0x08ccbaf8 **" when using [pipe], for example the pipe-help patch.
bis denn! martin
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thanks - same here.
Wierd since I haven't touched the 'pipe' source since at least a year ago. I'll check it out.
M
On Mon, Aug 25, 2014 at 04:42:55PM +0200, Cyrille Henry wrote:
same here. cheers c
Le 25/08/2014 16:38, martin brinkmann a écrit :
On 24/08/14 02:33, Miller Puckette wrote:
OK... hopefully foxed now. THanks as always for flagging it.
Test 4 is out on git and on http://msp.ucsd.edu/software.html
thanks, this looks right now.
but i get either a segfault or "double free or corruption (fasttop): 0x08ccbaf8 **" when using [pipe], for example the pipe-help patch.
bis denn! martin
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sam, 2014-08-23 at 17:33 -0700, Miller Puckette wrote:
OK... hopefully foxed now. THanks as always for flagging it.
Test 4 is out on git and on http://msp.ucsd.edu/software.html
I found a crasher and I think the problem got introduced somewhere between the latest 0.45 and the 0.46.test3 release. The test patch is quite simple:
[1, 2( | [pipe 3]
Clicking once or twice on the message box crashes Pd. This is on Ubuntu 14.04 i386.
Roman
*** Error in `/usr/local/bin/pd': double free or corruption (fasttop): 0x08260868 ***
Program received signal SIGABRT, Aborted. 0xb7fdd424 in __kernel_vsyscall () (gdb) (gdb) backtrace #0 0xb7fdd424 in __kernel_vsyscall () #1 0xb7cd3937 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #2 0xb7cd6d63 in __GI_abort () at abort.c:89 #3 0xb7d0eaa3 in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0xb7e0bbfc "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175 #4 0xb7d18f8a in malloc_printerr (action=<optimized out>, str=0xb7e0bdc0 "double free or corruption (fasttop)", ptr=0x8260868) at malloc.c:4996 #5 0xb7d19bfd in _int_free (av=0xb7e51420 <main_arena>, p=<optimized out>, have_lock=0) at malloc.c:3840 #6 0x081105c3 in hang_tick () #7 0x080c5959 in sched_tick () #8 0x080c6925 in m_mainloop ()
#9 0x080566db in main ()
Sure enough - I broke pipe trying to stop a memory leak. I think it's fixed now in git.
thanks M
On Mon, Aug 25, 2014 at 11:11:46PM +0200, Roman Haefeli wrote:
On Sam, 2014-08-23 at 17:33 -0700, Miller Puckette wrote:
OK... hopefully foxed now. THanks as always for flagging it.
Test 4 is out on git and on http://msp.ucsd.edu/software.html
I found a crasher and I think the problem got introduced somewhere between the latest 0.45 and the 0.46.test3 release. The test patch is quite simple:
[1, 2( | [pipe 3]
Clicking once or twice on the message box crashes Pd. This is on Ubuntu 14.04 i386.
Roman
*** Error in `/usr/local/bin/pd': double free or corruption (fasttop): 0x08260868 ***
Program received signal SIGABRT, Aborted. 0xb7fdd424 in __kernel_vsyscall () (gdb) (gdb) backtrace #0 0xb7fdd424 in __kernel_vsyscall () #1 0xb7cd3937 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #2 0xb7cd6d63 in __GI_abort () at abort.c:89 #3 0xb7d0eaa3 in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0xb7e0bbfc "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175 #4 0xb7d18f8a in malloc_printerr (action=<optimized out>, str=0xb7e0bdc0 "double free or corruption (fasttop)", ptr=0x8260868) at malloc.c:4996 #5 0xb7d19bfd in _int_free (av=0xb7e51420 <main_arena>, p=<optimized out>, have_lock=0) at malloc.c:3840 #6 0x081105c3 in hang_tick () #7 0x080c5959 in sched_tick () #8 0x080c6925 in m_mainloop ()
#9 0x080566db in main ()
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Sorry for double-reporting it, I only saw Martin Brinkmann's report later. Thanks for the fix.
Roman
On Mon, 2014-08-25 at 14:43 -0700, Miller Puckette wrote:
Sure enough - I broke pipe trying to stop a memory leak. I think it's fixed now in git.
thanks M
On Mon, Aug 25, 2014 at 11:11:46PM +0200, Roman Haefeli wrote:
On Sam, 2014-08-23 at 17:33 -0700, Miller Puckette wrote:
OK... hopefully foxed now. THanks as always for flagging it.
Test 4 is out on git and on http://msp.ucsd.edu/software.html
I found a crasher and I think the problem got introduced somewhere between the latest 0.45 and the 0.46.test3 release. The test patch is quite simple:
[1, 2( | [pipe 3]
Clicking once or twice on the message box crashes Pd. This is on Ubuntu 14.04 i386.
Roman
*** Error in `/usr/local/bin/pd': double free or corruption (fasttop): 0x08260868 ***
Program received signal SIGABRT, Aborted. 0xb7fdd424 in __kernel_vsyscall () (gdb) (gdb) backtrace #0 0xb7fdd424 in __kernel_vsyscall () #1 0xb7cd3937 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #2 0xb7cd6d63 in __GI_abort () at abort.c:89 #3 0xb7d0eaa3 in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0xb7e0bbfc "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175 #4 0xb7d18f8a in malloc_printerr (action=<optimized out>, str=0xb7e0bdc0 "double free or corruption (fasttop)", ptr=0x8260868) at malloc.c:4996 #5 0xb7d19bfd in _int_free (av=0xb7e51420 <main_arena>, p=<optimized out>, have_lock=0) at malloc.c:3840 #6 0x081105c3 in hang_tick () #7 0x080c5959 in sched_tick () #8 0x080c6925 in m_mainloop ()
#9 0x080566db in main ()
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Bektur -
Billy Stiltner -
Chris McCormick -
Cyrille Henry -
IOhannes m zmoelnig -
martin brinkmann -
Miller Puckette -
Oliver Larkin -
Roman Haefeli -
Tim E. Real