If you're worried by metro's irregularity then you should use Eric Lyons' samm~ (sample accurate multiple metronomes). This is described in http://www.sarc.qub.ac.uk/~elyon/LyonPapers/SampleAccurate-Lyon-ICMC2006.pdf
Note that samm~ is almost exactly as sample-accurate as Pd's metro. I tried to illustrate this in attached patch. samm~ however is also available for Max, where the metro according to Eric's paper is not as accurate as the one in Pd, so if you need to move patches between both systems, samm~ is a good choice. Of course Eric's system has some convenient extensions to generate polyrhythms etc., but timing alone IMO is no reason to exchange [metro] with [samm~] on Pd.
Cool patch, Frank. Note though that by converting the click signal from samm~ into a bang, you are rounding it to the nearest vector. As I showed in my demo at LAC, I can make metro perform poorly in a subpatch with a very large blocksize (say 4096), but samm~ will perform the same irrespective of blocksize.
It is true that samm~ and friends were originally written for MaxMSP to deal with its problematic event-level timing. OTOH as my paper points out, Pd's audio thread is more susceptible to interruption from GUI events than MaxMSP. In addition to convenience, The benefits of samm~ come from its integration into a system of signal-level triggering, particularly with the soundfile player called player~ which I think has some nice features.
Best,
Eric
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
---------- Forwarded message ---------- From: Frank Barknecht fbar@footils.org To: pd-list@iem.at Date: Sun, 18 Feb 2007 14:01:08 +0100 Subject: Re: [PD] Dynamic patching questions Hallo, Alexandre Quessy hat gesagt: // Alexandre Quessy wrote:
- Is the use of [namecanvas $0] recommended or totally deprecated ?
if you want to edit the content of subpatches I'd say it's totally deprecated because it's completely unnecessary, as every subpatch has its own receiver "pd-subpatchname" builtin. This also works for subpatch names containing $0 as: "pd-$0-subpatchname"
- Where can I find an abstraction or object to convert any familiar
representation of colors to the Tk colors (or whatever is used for GUI objects) ?
E.g. here: http://lists.puredata.info/pipermail/pd-list/2006-03/036005.html
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
---------- Forwarded message ---------- From: Yves Degoyon ydegoyon@free.fr To: Alexandre Quessy listes@sourcelibre.com Date: Sun, 18 Feb 2007 16:16:17 +0100 Subject: Re: [PD] Google Summer of Code
http://r23.cc/interface/ is a very nice example of audio streaming with server-side Pd.
hum, there is an update on this, the new map component is there : http://gollum.artefacte.org/mapuse/map.html
the map itself is not pd, but some emitters ( radios ) use pd patches to link this to a netjuke database that enables to make playlist and programation.
so, r23 itself uses pd, but the global infrastructure ( http://giss.tv ) allows to use any software to stream ( Muse, IceS, libshout, ... )
cheers, sevy
---------- Forwarded message ---------- From: Jamie Bullock jamie@postlude.co.uk To: marius schebella marius.schebella@gmail.com Date: Sun, 18 Feb 2007 15:21:30 +0000 Subject: Re: [PD] Re: infinite composing On Sat, 2007-02-17 at 19:19 -0500, marius schebella wrote:
the call is written in a way that makes me think, that the producers don't know to much about what is going on in the world... but maybe the reason is, that there is no such thing as a kiosk mode or a protection from changing the patch in pd.
There was a patch submitted by IOhannes to do this:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1529010...
Jamie
--===============0388656242==-- _______________________________________________ PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://lists.puredata.info/listinfo/pd-list
Hallo, Eric Lyon hat gesagt: // Eric Lyon wrote:
Cool patch, Frank. Note though that by converting the click signal from samm~ into a bang, you are rounding it to the nearest vector.
Hm, I actually only used click2bang~ to be able to do measurements with [timer]. In attached patch I removed that part, so the impulses are directly recorded to samm.wav. It still is in sync with [metro].
As I showed in my demo at LAC, I can make metro perform poorly in a subpatch with a very large blocksize (say 4096), but samm~ will perform the same irrespective of blocksize.
But weren't you showing this only for Max? Pd's [metro] doesn't care about the blocksize at all.
It is true that samm~ and friends were originally written for MaxMSP to deal with its problematic event-level timing. OTOH as my paper points out, Pd's audio thread is more susceptible to interruption from GUI events than MaxMSP.
But aren't samm~ etc. also derived from the audio thread, because they are signal externals? Then they should be just as shaky or solid as the clock-derived objects metro, delay etc., shouldn't they?
In addition to convenience, The benefits of samm~ come from its integration into a system of signal-level triggering, particularly with the soundfile player called player~ which I think has some nice features.
Yes, it's definitely a cool collection, and I'm glad to have it in the CVS soon. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hey all,
In addition to convenience, The benefits of samm~ come from its integration into a system of signal-level triggering,
what exactly is the difference of samm~ compared to the long time
existing iem t3 objects?
particularly with the soundfile player called player~ which I think has some nice features.
I'll definitely look into that one, although xsample also allows
signal controlled sample processing.
greetings, Thomas
Hi Thomas,
In addition to convenience, The benefits of samm~ come from its integration into a system of signal-level triggering,
what exactly is the difference of samm~ compared to the long time existing iem t3 objects?
t3 uses time tagged triggers, samm~ sends clicks that are not time tagged. BTW in Pd-extended, the helpfile for t3_sig~ relies on some missing externals: for++, t3_del, and hpl~.
particularly with the soundfile player called player~ which I think has some nice features.
I'll definitely look into that one, although xsample also allows signal controlled sample processing.
Both groove~ and xsample~ have a lot more features than player~. The two features I likely about player~ are internal polyphony and sample-accurate triggering. (Perhaps xsample~ can do that too?)
Best,
Eric
Hi Eric,
what exactly is the difference of samm~ compared to the long time existing iem t3 objects?
t3 uses time tagged triggers, samm~ sends clicks that are not time tagged.
I see, are there other advantages (cpu-wise maybe)? Since these
periodic clicks could also be generated with t3-based abstractions.
particularly with the soundfile player called player~ which I think has some
nice
features.
I'll definitely look into that one, although xsample also allows signal controlled sample processing.
Both groove~ and xsample~ have a lot more features than player~. The two features I likely about player~ are internal polyphony and sample-accurate triggering. (Perhaps xsample~ can do that too?)
xsample can do sample-accurate triggering, but has no internal
polyphony.
greetings, Thomas
-- Thomas Grill http://grrrr.org
t3 uses time tagged triggers, samm~ sends clicks that are not time tagged.
I see, are there other advantages (cpu-wise maybe)? Since these periodic clicks could also be generated with t3-based abstractions.
If anything I would expect t3 to be more cpu-efficient, but the CPU usage of samm~ is so low that probably the two approaches are interchangeable. I would be curious to see an example t3-based abstraction that does sample accurate metronome clicks. I think the main advantage of samm~ is convenience. It's nice to be able to set up a bunch of synched sample accurate metronomes, all at different speeds, without giving much thought to the underlying mechanisms. According to jkc at Cycling '74 all of the functionality of my system of sample accurate objects could be replicated with MaxMSP core objects, and I believe him. It would just be more awkward to do it the native way in many cases.
Best,
Eric
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
what exactly is the difference of samm~ compared to the long time
existing iem t3 objects?
Which reminds me: Aren't the t3_* objects superfluous since we have vline~?
I mean, instead of t3_bpe, t3_delay, t3_line~, t3_metro, t3_sig~ and t3_timer we could use vline~, delay, vline~, metro, vline~ and timer now and we would get exactly the same result except that t3 counts in samples and needs an additional float prepended to every message while vline~ wants milliseconds and works with regular messages.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
I mean, instead of t3_bpe, t3_delay, t3_line~, t3_metro, t3_sig~ and t3_timer we could use vline~, delay, vline~, metro, vline~ and timer now and we would get exactly the same result except that t3 counts in samples
Ah, sorry: t3 counts in msecs as well.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
what exactly is the difference of samm~ compared to the long time
existing iem t3 objects?Which reminds me: Aren't the t3_* objects superfluous since we have vline~?
yes, iem_t3 is superfluous. however, it is still there for historical reasons (there are patches that depend on iem_t3)
mfgasdr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
yes, iem_t3 is superfluous. however, it is still there for historical reasons (there are patches that depend on iem_t3)
For example rrad.angriff~.pd ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
With all this talk, it would be interesting to actually get a copy of these externals to try them out. Are these posted somewhere? Thanks,
Mike
On 2/18/07, Eric Lyon audiodidact@gmail.com wrote:
If you're worried by metro's irregularity then you should use Eric Lyons' samm~ (sample accurate multiple metronomes). This is described in http://www.sarc.qub.ac.uk/~elyon/LyonPapers/SampleAccurate-Lyon-ICMC2006.pdf
Note that samm~ is almost exactly as sample-accurate as Pd's metro. I tried to illustrate this in attached patch. samm~ however is also available for Max, where the metro according to Eric's paper is not as accurate as the one in Pd, so if you need to move patches between both systems, samm~ is a good choice. Of course Eric's system has some convenient extensions to generate polyrhythms etc., but timing alone IMO is no reason to exchange [metro] with [samm~] on Pd.
Cool patch, Frank. Note though that by converting the click signal from samm~ into a bang, you are rounding it to the nearest vector. As I showed in my demo at LAC, I can make metro perform poorly in a subpatch with a very large blocksize (say 4096), but samm~ will perform the same irrespective of blocksize.
It is true that samm~ and friends were originally written for MaxMSP to deal with its problematic event-level timing. OTOH as my paper points out, Pd's audio thread is more susceptible to interruption from GUI events than MaxMSP. In addition to convenience, The benefits of samm~ come from its integration into a system of signal-level triggering, particularly with the soundfile player called player~ which I think has some nice features.
Best,
Eric
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
---------- Forwarded message ---------- From: Frank Barknecht fbar@footils.org To: pd-list@iem.at Date: Sun, 18 Feb 2007 14:01:08 +0100 Subject: Re: [PD] Dynamic patching questions Hallo, Alexandre Quessy hat gesagt: // Alexandre Quessy wrote:
- Is the use of [namecanvas $0] recommended or totally deprecated ?
if you want to edit the content of subpatches I'd say it's totally deprecated because it's completely unnecessary, as every subpatch has its own receiver "pd-subpatchname" builtin. This also works for subpatch names containing $0 as: "pd-$0-subpatchname"
- Where can I find an abstraction or object to convert any familiar
representation of colors to the Tk colors (or whatever is used for GUI objects) ?
E.g. here: http://lists.puredata.info/pipermail/pd-list/2006-03/036005.html
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
---------- Forwarded message ---------- From: Yves Degoyon ydegoyon@free.fr To: Alexandre Quessy listes@sourcelibre.com Date: Sun, 18 Feb 2007 16:16:17 +0100 Subject: Re: [PD] Google Summer of Code
http://r23.cc/interface/ is a very nice example of audio streaming with server-side Pd.
hum, there is an update on this, the new map component is there : http://gollum.artefacte.org/mapuse/map.html
the map itself is not pd, but some emitters ( radios ) use pd patches to link this to a netjuke database that enables to make playlist and programation.
so, r23 itself uses pd, but the global infrastructure ( http://giss.tv ) allows to use any software to stream ( Muse, IceS, libshout, ... )
cheers, sevy
---------- Forwarded message ---------- From: Jamie Bullock jamie@postlude.co.uk To: marius schebella marius.schebella@gmail.com Date: Sun, 18 Feb 2007 15:21:30 +0000 Subject: Re: [PD] Re: infinite composing On Sat, 2007-02-17 at 19:19 -0500, marius schebella wrote:
the call is written in a way that makes me think, that the producers don't know to much about what is going on in the world... but maybe the reason is, that there is no such thing as a kiosk mode or a protection from changing the patch in pd.
There was a patch submitted by IOhannes to do this:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1529010...
Jamie
--===============0388656242==-- _______________________________________________ PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Eric Lyon -
Frank Barknecht -
IOhannes m zmoelnig -
Mike McGonagle -
Thomas Grill