hi, google earth uses a special format to save geo information data (kml files). I am trying to build a (simple) gem earth projector and read these files (and also some other file types...) The conversion should be easy, but precision might become a problem. this is a shape in kml file format (longitude, latitude, height)
<coordinates> -112.3348783983763,36.1514008468736,100 -112.3372535345629,36.14888517553886,100 -112.3356068927954,36.14781612679284,100 -112.3350034807972,36.14846469024177,100 -112.3358353861232,36.1489624162954,100 -112.3345888301373,36.15026229372507,100 -112.3337937856278,36.14978096026463,100 -112.3331798208424,36.1504472788618,100 -112.3348783983763,36.1514008468736,100 </coordinates> the precision is 16 digits, so I guess double float. does anyonw know, if opengl can handle that? or any quick ideas for how to approach that? marius.
If I'm doing it right, single precision float should be able to represent latitude and longitude to within about two meters.
If more precision than that is needed, you'll want to use "tr" to change periods (as well as commas) into spaces so that you get lines like: -112 3348783983763 36 1514008468736 100 Then filter for whatever range of integer latitudes and longitudes you're actually looking at. Then you should get 1 degree x 2^-24, better than a centimeter.
cheers Miller
On Thu, Dec 13, 2007 at 11:51:14AM -0500, marius schebella wrote:
hi, google earth uses a special format to save geo information data (kml files). I am trying to build a (simple) gem earth projector and read these files (and also some other file types...) The conversion should be easy, but precision might become a problem. this is a shape in kml file format (longitude, latitude, height)
<coordinates> -112.3348783983763,36.1514008468736,100 -112.3372535345629,36.14888517553886,100 -112.3356068927954,36.14781612679284,100 -112.3350034807972,36.14846469024177,100 -112.3358353861232,36.1489624162954,100 -112.3345888301373,36.15026229372507,100 -112.3337937856278,36.14978096026463,100 -112.3331798208424,36.1504472788618,100 -112.3348783983763,36.1514008468736,100 </coordinates> the precision is 16 digits, so I guess double float. does anyonw know, if opengl can handle that? or any quick ideas for how to approach that? marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 13 Dec 2007, Miller Puckette wrote:
If I'm doing it right, single precision float should be able to represent latitude and longitude to within about two meters.
longitude has to be from -180 to 180. The epsilon is then the previous power of two divided by 2^23. In metres this is 0.61 metre near equator. This is the worst case. For latitude the precision is twice better than longitude at equator. In northern europe and in alaska, the longitude precision is the same as the latitude precision.
It's twice more precise to use signed values than unsigned values, which is why I wouldn't use longitudes from 0 to 360.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Thu, 13 Dec 2007, Mathieu Bouchard wrote:
longitude has to be from -180 to 180. The epsilon is then the previous power of two divided by 2^23. In metres this is 0.61 metre near equator. This is the worst case. For latitude the precision is twice better than longitude at equator. In northern europe and in alaska, the longitude precision is the same as the latitude precision. It's twice more precise to use signed values than unsigned values, which is why I wouldn't use longitudes from 0 to 360.
Oh duh, my computation was wrong.
A degree is about 111319 metres of longitude around the equator, or 111138 metres of latitude. The max longitude error is 2^-16 degree or 1.69 metre and the max latitude error is 2^-17 degree or 0.85 metre. I don't remember how I computed it the first time.
You can get twice better worst case by using values ranging from -1 to +1 (because 1 is a power of two, so it lies at the boundary of a new precision level)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Thu, 13 Dec 2007, Mathieu Bouchard wrote:
You can get twice better worst case by using values ranging from -1 to +1 (because 1 is a power of two, so it lies at the boundary of a new precision level)
There was also a mistake in saying that. It improves precision, but only by a factor of 180/128.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
for now, I am ok with a precision of 1cm. but what is highest positive integer number I can represent with the current pd float precision? 16bit? 32.767? (btw., would be nice to have this information in the float/number helppatch) that would only give me a precision of around 3.4 meters... marius.
Mathieu Bouchard wrote:
On Thu, 13 Dec 2007, Mathieu Bouchard wrote:
You can get twice better worst case by using values ranging from -1 to +1 (because 1 is a power of two, so it lies at the boundary of a new precision level)
There was also a mistake in saying that. It improves precision, but only by a factor of 180/128.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Mon, 17 Dec 2007, marius schebella wrote:
for now, I am ok with a precision of 1cm.
You won't get it with just floats. You will have to use pairs of floats to get to this level.
but what is highest positive integer number I can represent with the current pd float precision? 16bit? 32.767?
the highest positive integer is 340282346638528859811704183484516925440 but you really want to know which is the highest positive integer for which it is possible to subtract 1. It's 16777216 (I'm saying this number very often on pd-list).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Mathieu Bouchard wrote:
but what is highest positive integer number I can represent with the current pd float precision? 16bit? 32.767?
the highest positive integer is 340282346638528859811704183484516925440 but you really want to know which is the highest positive integer for which it is possible to subtract 1. It's 16777216 (I'm saying this number very often on pd-list).
that is true, maybe because this information is missing in the help patch. so, when I type this number into a number box, it says 1.67772e+07 but it still seems to work, because I can subtract 16777216 correctly.
for now, I am ok with a precision of 1cm.
You won't get it with just floats. You will have to use pairs of floats to get to this level.
I separate the longitude values at the comma, which means this number (16777216) has to represent a range of ~111 km which gives a precision of less than 0.7cm. marius.
hi.
I am currently working on an external that generates rhythmic pulses in a certain way. But I was wondering if I could run into problems with calling usleep in an external. Alternatively, I suppose i could use a pd timer as an input and let it give a bang each milli-second, but that doesn't seem like a good idea to me.
I suppose externals are all separate threads, or am I wrong about that?
Regards,
yvan vander sanden
Yvan Vander Sanden wrote:
hi.
I am currently working on an external that generates rhythmic pulses in a certain way. But I was wondering if I could run into problems with calling usleep in an external. Alternatively, I suppose i could use a pd timer as an input and let it give a bang each milli-second, but that doesn't seem like a good idea to me.
I suppose externals are all separate threads, or am I wrong about that?
No they are all in the same thread as pd unless you start another thread inside the external. If you want your external to sleep you'll need to make a new thread, as in the tcpclient code.
Martin
On Dec 15, 2007 6:24 PM, Yvan Vander Sanden yvan@youngmusic.org wrote:
hi.
I am currently working on an external that generates rhythmic pulses in a certain way. But I was wondering if I could run into problems with calling usleep in an external. Alternatively, I suppose i could use a pd timer as an input and let it give a bang each milli-second, but that doesn't seem like a good idea to me.
[metro 1] creates a bang each millisecond, approximately. The message rate is constrained by the block size, so you would want to put [metro 1] inside of a subpatch with [block~ 1] for best time resolution. You can't get your messages to resolve at *exactly* each millisecond in pd, no matter how you do it-but [metro 1] gives you 1-ms bangs with an error of at most 1/44.1 ms, using [block~ 1] and sampling freq 44.1 kHz --I guess if you use a sample rate that is a multiple of 1,000 you can get exactly milliseconds between bangs.
Chuck
I suppose externals are all separate threads, or am I wrong about that?
Regards,
yvan vander sanden
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Charles Henry hat gesagt: // Charles Henry wrote:
[metro 1] creates a bang each millisecond, approximately. The message rate is constrained by the block size, so you would want to put [metro 1] inside of a subpatch with [block~ 1] for best time resolution.
That's not true. Message rate is not related to the dsp vector size.
You can't get your messages to resolve at *exactly* each millisecond in pd, no matter how you do it-but [metro 1] gives you 1-ms bangs with an error of at most 1/44.1 ms, using [block~ 1] and sampling freq 44.1 kHz
--I guess if you use a sample rate that is a multiple of 1,000 you can get exactly milliseconds between bangs.
Of course every action in an digital audio system has to happen on a sample, but Pd's clock-delayed messages calculate time as a continuum (in float-resolution), not quantized to samples, so they are able to calculate times in between samples. And again: You don't need any [block~ 1] to get that accuracy in metro. Try it yourself with a phasor~-clone build from metro and vline~!
Ciao
Frank Barknecht _ ______footils.org__
On Dec 17, 2007 3:03 AM, Frank Barknecht fbar@footils.org wrote:
Hallo, Charles Henry hat gesagt: // Charles Henry wrote:
[metro 1] creates a bang each millisecond, approximately. The message rate is constrained by the block size, so you would want to put [metro 1] inside of a subpatch with [block~ 1] for best time resolution.
That's not true. Message rate is not related to the dsp vector size.
My mistake. I thought messages had to run in between dsp blocks.
You can't get your messages to resolve at *exactly* each millisecond in pd, no matter how you do it-but [metro 1] gives you 1-ms bangs with an error of at most 1/44.1 ms, using [block~ 1] and sampling freq 44.1 kHz
--I guess if you use a sample rate that is a multiple of 1,000 you can get exactly milliseconds between bangs.
Of course every action in an digital audio system has to happen on a sample, but Pd's clock-delayed messages calculate time as a continuum (in float-resolution), not quantized to samples, so they are able to calculate times in between samples. And again: You don't need any [block~ 1] to get that accuracy in metro. Try it yourself with a phasor~-clone build from metro and vline~!
I see now. That works well up to 1000 Hz.
Chuck
Ciao
Frank Barknecht _ ______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi all,
Charles Henry wrote:
On Dec 17, 2007 3:03 AM, Frank Barknecht fbar@footils.org wrote:
Hallo, Charles Henry hat gesagt: // Charles Henry wrote:
[metro 1] creates a bang each millisecond, approximately. The message rate is constrained by the block size, so you would want to put [metro 1] inside of a subpatch with [block~ 1] for best time resolution.
That's not true. Message rate is not related to the dsp vector size.
My mistake. I thought messages had to run in between dsp blocks.
Someone please refresh/adjust my memory... what IS the message rate in PD? I also thought it was related to block size all these years. And how can it be changed if needed?
d.
Derek Holzer wrote:
Hi all,
Charles Henry wrote:
On Dec 17, 2007 3:03 AM, Frank Barknecht fbar@footils.org wrote:
Hallo, Charles Henry hat gesagt: // Charles Henry wrote:
[metro 1] creates a bang each millisecond, approximately. The message rate is constrained by the block size, so you would want to put [metro 1] inside of a subpatch with [block~ 1] for best time resolution.
That's not true. Message rate is not related to the dsp vector size.
My mistake. I thought messages had to run in between dsp blocks.
Someone please refresh/adjust my memory... what IS the message rate in PD? I also thought it was related to block size all these years. And how can it be changed if needed?
There is no fixed rate, it's event-based with continuous time (or as continuous as floating point numbers gets you). But - it works with "logical" time, any relationship to "real" time is purely a coincidence.
Claude
Thanks, Zen-Master Claudius. Your quantum revelations still leave me wondering, however, what is the minimum time between two events which can be scheduled?
I teach my students that the reason you can't send audio to "message" (i.e. non-audio) objects is that "message" objects run slower. While this may not be "logically" correct to many of the hackers that live on this list, it is a convenient way to explain the difference to artists just beginning in this world. Block size was the technical answer I gave.
Now that I know this is false, I need a new explanation. Plus I'd like to know what the limits of message processing speed are. In "real time", please.
best, d.
Claude Heiland-Allen wrote:
Derek Holzer wrote:
Hi all,
Charles Henry wrote:
On Dec 17, 2007 3:03 AM, Frank Barknecht fbar@footils.org wrote:
Hallo, Charles Henry hat gesagt: // Charles Henry wrote:
[metro 1] creates a bang each millisecond, approximately. The message rate is constrained by the block size, so you would want to put [metro 1] inside of a subpatch with [block~ 1] for best time resolution.
That's not true. Message rate is not related to the dsp vector size.
My mistake. I thought messages had to run in between dsp blocks.
Someone please refresh/adjust my memory... what IS the message rate in PD? I also thought it was related to block size all these years. And how can it be changed if needed?
There is no fixed rate, it's event-based with continuous time (or as continuous as floating point numbers gets you). But - it works with "logical" time, any relationship to "real" time is purely a coincidence.
Claude
Derek Holzer wrote:
Thanks, Zen-Master Claudius. Your quantum revelations still leave me wondering, however, what is the minimum time between two events which can be scheduled?
[delay 0] works.
I teach my students that the reason you can't send audio to "message" (i.e. non-audio) objects is that "message" objects run slower. While this may not be "logically" correct to many of the hackers that live on this list, it is a convenient way to explain the difference to artists just beginning in this world. Block size was the technical answer I gave.
You can send audio to message objects, eg: [tabsend~]. What you can't do is have a ( message -> non-clock-aware-audio -> message ) turnaround less than a block size, as all messages that can affect an audio block are computed before the audio block is computed.
Now that I know this is false, I need a new explanation. Plus I'd like to know what the limits of message processing speed are. In "real time", please.
Actually, "message" time is in advance of "audio" time, which is in advance of "real" time: a message sent to a [vline~] logically occurs in the future, compared to the time the [vline~] starts computing the particular audio block when the event will have occured, which is in the future compared to the "real" time when the audio plays. (Sorry for tense confusion, it's tricky...).
message computation happens before audio computation happens before audio playback
Pd has no notion of "real" time, only "logical" time, of which "audio logical time" is as close to real time as you are likely to get if you don't overload your CPU and cause dropouts.
The limit of message processing speed depends on how fast your CPU is compared to the messages you want to process. No CPU is fast enough to compute ( "bang"--[until] ) in a finite time...
Claude
BTW, I like how I can turn on [pix_write] and [writesf~] and have everything work in logical time (with very many dropouts) and the final video be in perfect sync with the sound. Using [gemhead] for sequencing the audio is kinda fun too, but I'm just afraid I'll get bored with 125bpm ;)
best, d.
Claude Heiland-Allen wrote:
Derek Holzer wrote:
Hi all,
Charles Henry wrote:
On Dec 17, 2007 3:03 AM, Frank Barknecht fbar@footils.org wrote:
Hallo, Charles Henry hat gesagt: // Charles Henry wrote:
[metro 1] creates a bang each millisecond, approximately. The message rate is constrained by the block size, so you would want to put [metro 1] inside of a subpatch with [block~ 1] for best time resolution.
That's not true. Message rate is not related to the dsp vector size.
My mistake. I thought messages had to run in between dsp blocks.
Someone please refresh/adjust my memory... what IS the message rate in PD? I also thought it was related to block size all these years. And how can it be changed if needed?
There is no fixed rate, it's event-based with continuous time (or as continuous as floating point numbers gets you). But - it works with "logical" time, any relationship to "real" time is purely a coincidence.
Claude
Hi Claude,
OK, thanks for going into it a bit more. Makes sense to me, of course, but I'll have to chew on it a while and think of a way to communicate it without twisting up people's heads too much at too early a part of the workshops ;-)
Still, it is an inherent part of PD that you keep messages and audio separate. Thus the different graphical look of the patch cables, and the fact that it will not let you connect an audio cable to a non-audio object. There must be some reason for this, and speed of the objects is what I thought it was.
best, d.
Claude Heiland-Allen wrote:
Derek Holzer wrote:
Thanks, Zen-Master Claudius. Your quantum revelations still leave me wondering, however, what is the minimum time between two events which can be scheduled?
[delay 0] works.
I teach my students that the reason you can't send audio to "message" (i.e. non-audio) objects is that "message" objects run slower. While this may not be "logically" correct to many of the hackers that live on this list, it is a convenient way to explain the difference to artists just beginning in this world. Block size was the technical answer I gave.
You can send audio to message objects, eg: [tabsend~]. What you can't do is have a ( message -> non-clock-aware-audio -> message ) turnaround less than a block size, as all messages that can affect an audio block are computed before the audio block is computed.
Now that I know this is false, I need a new explanation. Plus I'd like to know what the limits of message processing speed are. In "real time", please.
Actually, "message" time is in advance of "audio" time, which is in advance of "real" time: a message sent to a [vline~] logically occurs in the future, compared to the time the [vline~] starts computing the particular audio block when the event will have occured, which is in the future compared to the "real" time when the audio plays. (Sorry for tense confusion, it's tricky...).
message computation happens before audio computation happens before audio playback
Pd has no notion of "real" time, only "logical" time, of which "audio logical time" is as close to real time as you are likely to get if you don't overload your CPU and cause dropouts.
The limit of message processing speed depends on how fast your CPU is compared to the messages you want to process. No CPU is fast enough to compute ( "bang"--[until] ) in a finite time...
Claude
BTW, I like how I can turn on [pix_write] and [writesf~] and have everything work in logical time (with very many dropouts) and the final video be in perfect sync with the sound. Using [gemhead] for sequencing the audio is kinda fun too, but I'm just afraid I'll get bored with 125bpm ;)
best, d.
Claude Heiland-Allen wrote:
Derek Holzer wrote:
Hi all,
Charles Henry wrote:
On Dec 17, 2007 3:03 AM, Frank Barknecht fbar@footils.org wrote:
Hallo, Charles Henry hat gesagt: // Charles Henry wrote:
> [metro 1] creates a bang each millisecond, approximately. The > message > rate is constrained by the block size, so you would want to put > [metro > 1] inside of a subpatch with [block~ 1] for best time resolution. That's not true. Message rate is not related to the dsp vector size.
My mistake. I thought messages had to run in between dsp blocks.
Someone please refresh/adjust my memory... what IS the message rate in PD? I also thought it was related to block size all these years. And how can it be changed if needed?
There is no fixed rate, it's event-based with continuous time (or as continuous as floating point numbers gets you). But - it works with "logical" time, any relationship to "real" time is purely a coincidence.
Claude
Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote:
OK, thanks for going into it a bit more. Makes sense to me, of course, but I'll have to chew on it a while and think of a way to communicate it without twisting up people's heads too much at too early a part of the workshops ;-)
Actually for workshops it's easy: A [metro 1] will send a bang every 1 msecs, regardless what's happening with audio. Nothing complicated about that. In Max/MSP it's more complicated, as a [metro 1] may send bangs with varying periods of not always 1msec. But Pd is easy.
Though, even in Pd, GUI messages are treated special: If you click on a [bang( message, this will only be evaluated every 64 samples. But you probably cannot click the mouse repeatedly with a constant 1 msec period anyways, so it shouldn't matter.
The second thing, people need to learn then is, that most signal objects can only be scheduled on block boundaries. So if you send a new frequency to an [osc~] as a float message, the osc~ will not respond immediatly, as it has already calculated the next block of samples. So the new frequency can only be taken into account for the next block after that. IIR block here means 64 samples always, regardless of block~ size. But I may be wrong about that.
[vline~] is one of the few special objects which additionally can "look into the future" and change it's value kind of in the middle of a block (other objects like that are vsnapshot~ and Claude's wonderful analogue-envelope generator - and I'm working on making the as of now unreleased lua~/vessel~ external clock-aware, too). But this "see the future" only works for messages, that Pd already knows about, and these are messages that originate in a clock-based object like metro, delay, pipe, etc. Messages not coming from there, i.e. GUI messages, cannot be known in advance of course. But as these are quantized to 64 samples anyway, it doesn't matter most of the time.
Ciao
Frank Barknecht _ ______footils.org__
This is all fine and dandy.
But what about when they ask why they can't connect [osc~ 440] to [+ 1], for example. Why won't PD let the connection get made? I.e., why can't audio go to message objects?
d.
Frank Barknecht wrote:
Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote:
OK, thanks for going into it a bit more. Makes sense to me, of course, but I'll have to chew on it a while and think of a way to communicate it without twisting up people's heads too much at too early a part of the workshops ;-)
Actually for workshops it's easy: A [metro 1] will send a bang every 1 msecs, regardless what's happening with audio. Nothing complicated about that. In Max/MSP it's more complicated, as a [metro 1] may send bangs with varying periods of not always 1msec. But Pd is easy.
Though, even in Pd, GUI messages are treated special: If you click on a [bang( message, this will only be evaluated every 64 samples. But you probably cannot click the mouse repeatedly with a constant 1 msec period anyways, so it shouldn't matter.
The second thing, people need to learn then is, that most signal objects can only be scheduled on block boundaries. So if you send a new frequency to an [osc~] as a float message, the osc~ will not respond immediatly, as it has already calculated the next block of samples. So the new frequency can only be taken into account for the next block after that. IIR block here means 64 samples always, regardless of block~ size. But I may be wrong about that.
[vline~] is one of the few special objects which additionally can "look into the future" and change it's value kind of in the middle of a block (other objects like that are vsnapshot~ and Claude's wonderful analogue-envelope generator - and I'm working on making the as of now unreleased lua~/vessel~ external clock-aware, too). But this "see the future" only works for messages, that Pd already knows about, and these are messages that originate in a clock-based object like metro, delay, pipe, etc. Messages not coming from there, i.e. GUI messages, cannot be known in advance of course. But as these are quantized to 64 samples anyway, it doesn't matter most of the time.
Ciao
Sorry, I read this now and it sounds idiotic! Of course, I know why (one is programmed for DSP and one is not). But again, I thought the difference was that message objects were calculated slower, ie. at block boundaries, which in fact is the restriction of DSP objects! So now that I've been told that actually DSP objects are "slower", it shakes up my world view a bit, so I'm looking for new metaphors to get it back together ;-)
d.
Derek Holzer wrote:
This is all fine and dandy.
But what about when they ask why they can't connect [osc~ 440] to [+ 1], for example. Why won't PD let the connection get made? I.e., why can't audio go to message objects?
d.
Frank Barknecht wrote:
Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote:
OK, thanks for going into it a bit more. Makes sense to me, of course, but I'll have to chew on it a while and think of a way to communicate it without twisting up people's heads too much at too early a part of the workshops ;-)
Actually for workshops it's easy: A [metro 1] will send a bang every 1 msecs, regardless what's happening with audio. Nothing complicated about that. In Max/MSP it's more complicated, as a [metro 1] may send bangs with varying periods of not always 1msec. But Pd is easy.
Though, even in Pd, GUI messages are treated special: If you click on a [bang( message, this will only be evaluated every 64 samples. But you probably cannot click the mouse repeatedly with a constant 1 msec period anyways, so it shouldn't matter.
The second thing, people need to learn then is, that most signal objects can only be scheduled on block boundaries. So if you send a new frequency to an [osc~] as a float message, the osc~ will not respond immediatly, as it has already calculated the next block of samples. So the new frequency can only be taken into account for the next block after that. IIR block here means 64 samples always, regardless of block~ size. But I may be wrong about that.
[vline~] is one of the few special objects which additionally can "look into the future" and change it's value kind of in the middle of a block (other objects like that are vsnapshot~ and Claude's wonderful analogue-envelope generator - and I'm working on making the as of now unreleased lua~/vessel~ external clock-aware, too). But this "see the future" only works for messages, that Pd already knows about, and these are messages that originate in a clock-based object like metro, delay, pipe, etc. Messages not coming from there, i.e. GUI messages, cannot be known in advance of course. But as these are quantized to 64 samples anyway, it doesn't matter most of the time.
Ciao
Derek Holzer wrote:
So now that I've been told that actually DSP objects are "slower", it shakes up my world view a bit, so I'm looking for new metaphors to get it back together ;-)
all the "slower" vs "faster" is non-sense.
signals are handled in a _synchronous_ way (they have to process 44100 samples per second; synchronized with the soundcard); they do this continuosly (once you have started the audio-engine they will process 44100 samples/sec until the end of the world, or the audio engine gets stopped)
messages are handled in an _asynchronous_ way: "they happen on demand!"; they might occur every now and then; two messages might occur at the same logical time,...
so all in all, messages are way more powerful than signals.
unfortunately, CPU is not. that is one reason, why the oh-so-powerful messages are not used for signal processing.
mfg.asdr IOhannes
OK, now I've got it. This can be explained! It especially makes sense with the old "infinite looping" counter patch:
[f]X[+ 1]
where [+ 1] gets sent to the hot rather than the cold inlet of [f]. It wouldn't be such a problem if it only counted on signal blocks, but it actually counts as fast as the CPU will let it.
Great, concept is clear, I can continue!
best, d.
IOhannes m zmoelnig wrote:
Derek Holzer wrote:
So now that I've been told that actually DSP objects are "slower", it shakes up my world view a bit, so I'm looking for new metaphors to get it back together ;-)
all the "slower" vs "faster" is non-sense.
signals are handled in a _synchronous_ way (they have to process 44100 samples per second; synchronized with the soundcard); they do this continuosly (once you have started the audio-engine they will process 44100 samples/sec until the end of the world, or the audio engine gets stopped)
messages are handled in an _asynchronous_ way: "they happen on demand!"; they might occur every now and then; two messages might occur at the same logical time,...
so all in all, messages are way more powerful than signals.
unfortunately, CPU is not. that is one reason, why the oh-so-powerful messages are not used for signal processing.
mfg.asdr IOhannes
Here's a patch that outputs the actual time of the bangs from a metro, and also shows the phasor~ clone generated using vline~. You can see that the actual time that the metro outputs is +/- 5ms (on my system), but the phasor has a constant period anyways! Craziness.
So if I wanted to use PD to schedule some other program or device, would I want to send along some sort of timestamp based on the logical time to keep the timing tight? Perhaps this is a solution for some people who have been running into scheduling sloppiness when controlling hardware devices? It probably would be very doable to have an arduino do micro-scheduling of events based on a timestamp received along with the messages that are supposed to trigger the events.
is anybody doing this already?
-spencer
#N canvas 193 278 652 300 10; #X obj 62 136 realtime; #X obj 62 189 -; #X obj 62 160 t f f; #N canvas 0 0 450 300 graph1 0; #X array $0-waveform 1000 float 0; #X coords 0 1 999 -1 200 140 1; #X restore 395 68 graph; #X obj 62 217 print realtime; #X obj 201 162 vline~; #X msg 201 140 0 , 1 10; #X obj 254 162 metro 100; #X obj 139 86 metro 10; #X obj 139 109 t b b; #X obj 167 7 tgl 15 0 empty empty empty 0 -6 0 10 -262144 -1 -1 0 1 ; #X obj 167 28 t b f f; #X obj 200 186 tabwrite~ $0-waveform; #X connect 0 0 2 0; #X connect 1 0 4 0; #X connect 2 0 1 1; #X connect 2 1 1 0; #X connect 5 0 12 0; #X connect 6 0 5 0; #X connect 7 0 12 0; #X connect 8 0 9 0; #X connect 9 0 0 1; #X connect 9 1 6 0; #X connect 10 0 11 0; #X connect 11 0 0 0; #X connect 11 1 8 0; #X connect 11 2 7 0;
On Dec 17, 2007 11:58 AM, Derek Holzer derek@umatic.nl wrote:
OK, now I've got it. This can be explained! It especially makes sense with the old "infinite looping" counter patch:
[f]X[+ 1]
where [+ 1] gets sent to the hot rather than the cold inlet of [f]. It wouldn't be such a problem if it only counted on signal blocks, but it actually counts as fast as the CPU will let it.
Great, concept is clear, I can continue!
best, d.
IOhannes m zmoelnig wrote:
Derek Holzer wrote:
So now that I've been told that actually DSP objects are "slower", it shakes up my world view a bit, so I'm looking for new metaphors to get it back together ;-)
all the "slower" vs "faster" is non-sense.
signals are handled in a _synchronous_ way (they have to process 44100 samples per second; synchronized with the soundcard); they do this continuosly (once you have started the audio-engine they will process 44100 samples/sec until the end of the world, or the audio engine gets stopped)
messages are handled in an _asynchronous_ way: "they happen on demand!"; they might occur every now and then; two messages might occur at the same logical time,...
so all in all, messages are way more powerful than signals.
unfortunately, CPU is not. that is one reason, why the oh-so-powerful messages are not used for signal processing.
mfg.asdr IOhannes
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 22: "Be less critical more often"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I don't know if you fell into the same trap as me Derek (because it confused the heck out of me for ages), but if you've come from Csound, which is a true multi-rate system it's easy to see messages the wrong way. On one hand theres a useful analogy between Csound k-rate signals and the Pd message domain, on the other hand their rates are actually the other way around because Pd signal domain is much like Csound a-rate, but message domain is "fast as you like (timeless) logical time". That's why I've gradually trained myself to drop the habit of saying "control rate", when I mean "message domain".
On Mon, 17 Dec 2007 17:58:01 +0100 Derek Holzer derek@umatic.nl wrote:
OK, now I've got it. This can be explained! It especially makes sense with the old "infinite looping" counter patch:
[f]X[+ 1]
where [+ 1] gets sent to the hot rather than the cold inlet of [f]. It wouldn't be such a problem if it only counted on signal blocks, but it actually counts as fast as the CPU will let it.
Great, concept is clear, I can continue!
best, d.
IOhannes m zmoelnig wrote:
Derek Holzer wrote:
So now that I've been told that actually DSP objects are "slower", it shakes up my world view a bit, so I'm looking for new metaphors to get it back together ;-)
all the "slower" vs "faster" is non-sense.
signals are handled in a _synchronous_ way (they have to process 44100 samples per second; synchronized with the soundcard); they do this continuosly (once you have started the audio-engine they will process 44100 samples/sec until the end of the world, or the audio engine gets stopped)
messages are handled in an _asynchronous_ way: "they happen on demand!"; they might occur every now and then; two messages might occur at the same logical time,...
so all in all, messages are way more powerful than signals.
unfortunately, CPU is not. that is one reason, why the oh-so-powerful messages are not used for signal processing.
mfg.asdr IOhannes
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 22: "Be less critical more often"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 17 Dec 2007, IOhannes m zmoelnig wrote:
so all in all, messages are way more powerful than signals.
Especially as one could "reimplement" signals using messages as their base. Oops, this is already how signals are implemented! They have this method for the "dsp" selector. Granted that calling this method does not process the data, it merely sets up a stream through which the data is sent, but then, so is the "grid" selector in some other software.
unfortunately, CPU is not. that is one reason, why the oh-so-powerful messages are not used for signal processing.
It's quite doable to use messages for DSP and have it run fairly fast, if you use the same "fake pointers" as GEM/PDP/etc do, to point to a 64-float array. It could even just use lists of 64 floats and it wouldn't be that much slower. The only major thing you really lose is automatic fan-in, unless special additional tricks are used. Actually, Christian Klippel's Karma does DSP like that. The DSP compiler simply takes advantage of the exactly-one-block-per-tick characteristic of the signals, to save some % of the cpu and of the cache ram. This is one optimisation that can't be done on the message side, but there are many more optimisations that could be explored, on both sides separately and on both sides together.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote:
Sorry, I read this now and it sounds idiotic! Of course, I know why (one is programmed for DSP and one is not). But again, I thought the difference was that message objects were calculated slower, ie. at block boundaries, which in fact is the restriction of DSP objects! So now that I've been told that actually DSP objects are "slower", it shakes up my world view a bit, so I'm looking for new metaphors to get it back together ;-)
I'd suggest you do as I did and read Chapter 3: "Audio and control computations" in Miller's book several times, like 3 or 5 times (really). This is a deep issue and worth spending the time.
Ciao
Frank Barknecht _ ______footils.org__
Uh oh! There goes my Christmas weekend!
d.
Frank Barknecht wrote:
Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote:
Sorry, I read this now and it sounds idiotic! Of course, I know why (one is programmed for DSP and one is not). But again, I thought the difference was that message objects were calculated slower, ie. at block boundaries, which in fact is the restriction of DSP objects! So now that I've been told that actually DSP objects are "slower", it shakes up my world view a bit, so I'm looking for new metaphors to get it back together ;-)
I'd suggest you do as I did and read Chapter 3: "Audio and control computations" in Miller's book several times, like 3 or 5 times (really). This is a deep issue and worth spending the time.
Ciao
On Mon, 17 Dec 2007, Frank Barknecht wrote:
Though, even in Pd, GUI messages are treated special: If you click on a [bang( message, this will only be evaluated every 64 samples. But you probably cannot click the mouse repeatedly with a constant 1 msec period anyways, so it shouldn't matter.
There is no special code for handling GUI in this case. It just works the same as the rest does: each thing must be finished before you move to doing the next thing. This includes the GUI vs DSP interaction that you are talking about, which is only special to the extent that *you* look at it in a special way.
The second thing, people need to learn then is, that most signal objects can only be scheduled on block boundaries. So if you send a new frequency to an [osc~] as a float message, the osc~ will not respond immediatly, as it has already calculated the next block of samples. So the new frequency can only be taken into account for the next block after that. IIR block here means 64 samples always, regardless of block~ size. But I may be wrong about that.
I don't think that it would make sense that anything else than the object's effective block size would ever be used in that case. The point is to avoid the trouble of making a setting change during a block, because it requires remembering the old setting, the new setting, and the time at which it occurred, and it could change several times during the same block and the object would have to remember all of that. I can only suppose that it's not about 64, it's about the block size in use by the object in question.
I haven't tried it though.
AFAIK, the only restriction to 64 samples is a limitation of [dac~] and [adc~], so any objects you want to have more precision on, have to be in a different subpatch, because [block~] only operates on complete subpatches.
BTW, to add subblock precision to any float&signal inlet, change the inlet mode from float to signal (e.g. change [*~ 1] to [*~]) and use [vline~] to do a higher-precision kind of [signal~].
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Thanks for all the answers. The first ones were a lot of help, and although it seemed to me that you were all talking in tongues after that, it sure sounds interesting.
I checked out the tcpclient code by martin peach. The thread solution could be useful, but i also spotted something else: t_clock, clock_new etc. I think that is exactly what i need.
Until now I always used the end of Ioannes's externals tutorial as sort of a reference guide. I should have read that he only talks about some important functions, and not about all of them.
Now for the new question: is there a complete reference guide somewhere for pd types and functions you can use in externals? I did not really find one yet. But maybe I'm looking in the wrong places? (I'm somewhat hoping I don't have to scan through m_pd.h myself yet.)
Regards,
yvan
Hallo, Yvan Vander Sanden hat gesagt: // Yvan Vander Sanden wrote:
Thanks for all the answers. The first ones were a lot of help, and although it seemed to me that you were all talking in tongues after that, it sure sounds interesting.
I checked out the tcpclient code by martin peach. The thread solution could be useful, but i also spotted something else: t_clock, clock_new etc. I think that is exactly what i need.
Ah, yes. As you originally wanted to send out ryhthmic pulses, the clock functions are what you need. You could basically copy the code from [metro] or [delay] for this. The clocks will be (sub)sample accurate, as the "in tongues" discussion might have made clear.
Ciao
Frank Barknecht _ ______footils.org__
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Mon, 17 Dec 2007, Frank Barknecht wrote:
The second thing, people need to learn then is, that most signal objects can only be scheduled on block boundaries. So if you send a new frequency to an [osc~] as a float message, the osc~ will not respond immediatly, as it has already calculated the next block of samples. So the new frequency can only be taken into account for the next block after that. IIR block here means 64 samples always, regardless of block~ size. But I may be wrong about that.
I don't think that it would make sense that anything else than the object's effective block size would ever be used in that case. ...
I haven't tried it though.
You're right - and now I have tried it. Actually everything else indeed wouldn't make much sense.
BTW, to add subblock precision to any float&signal inlet, change the inlet mode from float to signal (e.g. change [*~ 1] to [*~]) and use [vline~] to do a higher-precision kind of [signal~].
This is fine for float messages, but other, meta-messages (reset etc., but also bang) sometimes need to be scheduled in a clock-aware fashion as well, that's when you need the additional work.
Ciao
Frank Barknecht _ ______footils.org__
On Mon, 17 Dec 2007, Derek Holzer wrote:
Still, it is an inherent part of PD that you keep messages and audio separate. Thus the different graphical look of the patch cables, and the fact that it will not let you connect an audio cable to a non-audio object. There must be some reason for this, and speed of the objects is what I thought it was.
It's just that a signal inlet doesn't know what to do with a non-signal input, and a non-signal inlet doesn't know what to do with a signal input. There's not much reason why the look of câbles wouldn't be different depending on whether they carry floats vs symbols vs whatever else. The GUI could also try to assist you more by investigating more about which connections don't make sense. There is a hint that Miller had such a thing in mind at one point and ended up not implementing it. You can see it in how outlet_new is defined and used: most classes declare a type for each of their outlets. Currently this is only used for signal vs non-signal, even though many classes define outlets with typenames like "float", "symbol", "pointer", "anything", ...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Dec 17, 2007 9:20 AM, Claude Heiland-Allen claudiusmaximus@goto10.org wrote:
BTW, I like how I can turn on [pix_write] and [writesf~] and have everything work in logical time (with very many dropouts) and the final video be in perfect sync with the sound. Using [gemhead] for sequencing the audio is kinda fun too, but I'm just afraid I'll get bored with 125bpm ;)
pix_record on OSX and Windows won't do this. A major problem with using video APIs with Pd is that the internal clock 'logical' time is nowhere close to the wall clock. Since these APIs need some time base reference to play back media properly 'logical' time is either subverted (pix_filmDarwin) or not used pix_record. It has been a terrible headache at times.
If you do something that interacts with reality, like sending something through [comport] using [metro] to schedule it, you will find that the actual messages show up on the serial connector on either side of the audio blocks, so that the average timing over a lot of messages is exact but any particular event will be within about 5 ms of the correct time.
Martin
Derek Holzer wrote:
To: Claude Heiland-Allen claudiusmaximus@goto10.org CC: pd-list@iem.at Subject: Re: [PD] timing question Date: Mon, 17 Dec 2007 15:55:28 +0100
Thanks, Zen-Master Claudius. Your quantum revelations still leave me wondering, however, what is the minimum time between two events which can be scheduled?
I teach my students that the reason you can't send audio to "message" (i.e. non-audio) objects is that "message" objects run slower. While this may not be "logically" correct to many of the hackers that live on this list, it is a convenient way to explain the difference to artists just beginning in this world. Block size was the technical answer I gave.
Now that I know this is false, I need a new explanation. Plus I'd like to know what the limits of message processing speed are. In "real time", please.
best, d.
Claude Heiland-Allen wrote:
Derek Holzer wrote:
Hi all,
Charles Henry wrote:
On Dec 17, 2007 3:03 AM, Frank Barknecht fbar@footils.org wrote:
Hallo, Charles Henry hat gesagt: // Charles Henry wrote:
[metro 1] creates a bang each millisecond, approximately. The
message
rate is constrained by the block size, so you would want to put
[metro
1] inside of a subpatch with [block~ 1] for best time resolution.
That's not true. Message rate is not related to the dsp vector size.
My mistake. I thought messages had to run in between dsp blocks.
Someone please refresh/adjust my memory... what IS the message rate in PD? I also thought it was related to block size all these years. And how can it be changed if needed?
There is no fixed rate, it's event-based with continuous time (or as continuous as floating point numbers gets you). But - it works with "logical" time, any relationship to "real" time is purely a coincidence.
Claude
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 81: "Go to an extreme, move back to a more comfortable place"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 17 Dec 2007, Derek Holzer wrote:
I teach my students that the reason you can't send audio to "message" (i.e. non-audio) objects is that "message" objects run slower.
The only ways that they run slower, is that: messages are only applied to audio between block boundaries; and doing audio processing with [+] takes a lot more cpu time than with [+~] because block processing takes a lot less messages to get the same job done. But for the latter, this is why there is GridFlow and VASP and stuff: they can handle many numbers in few messages.
While this may not be "logically" correct to many of the hackers that live on this list, it is a convenient way to explain the difference to artists just beginning in this world.
I also heard that babies are delivered by storks whenever mommy and daddy love each other very very much. I'm just beginning in this world so I get what I deserve.
Plus I'd like to know what the limits of message processing speed are. In "real time", please.
You can know that in realtime by using pd.
Try [realtime].
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On a closely related topic; Since Pd uses logical time why isn't there a "render mode" Csound style, for those occasions where you don't actually want to run in real time? Is it because blocking on unfinished output would leave no way for an object to notify that it had finished the computation?
On Mon, 17 Dec 2007 14:49:28 +0000 Claude Heiland-Allen claudiusmaximus@goto10.org wrote:
Derek Holzer wrote:
Hi all,
Charles Henry wrote:
On Dec 17, 2007 3:03 AM, Frank Barknecht fbar@footils.org wrote:
Hallo, Charles Henry hat gesagt: // Charles Henry wrote:
[metro 1] creates a bang each millisecond, approximately. The message rate is constrained by the block size, so you would want to put [metro 1] inside of a subpatch with [block~ 1] for best time resolution.
That's not true. Message rate is not related to the dsp vector size.
My mistake. I thought messages had to run in between dsp blocks.
Someone please refresh/adjust my memory... what IS the message rate in PD? I also thought it was related to block size all these years. And how can it be changed if needed?
There is no fixed rate, it's event-based with continuous time (or as continuous as floating point numbers gets you). But - it works with "logical" time, any relationship to "real" time is purely a coincidence.
Claude
http://claudiusmaximus.goto10.org
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Of course there's render mode....
downsample in pd patch- -> render to file via sfwrite~ or othe object --> upsample file with sndfile-convert or sound editor tool
should do the trick. Yes? At least to keep CPU limits from bottlenecking your render.
d.
Andy Farnell wrote:
On a closely related topic; Since Pd uses logical time why isn't there a "render mode" Csound style, for those occasions where you don't actually want to run in real time? Is it because blocking on unfinished output would leave no way for an object to notify that it had finished the computation?
On Mon, 17 Dec 2007 14:49:28 +0000 Claude Heiland-Allen claudiusmaximus@goto10.org wrote:
Derek Holzer wrote:
Hi all,
Charles Henry wrote:
On Dec 17, 2007 3:03 AM, Frank Barknecht fbar@footils.org wrote:
Hallo, Charles Henry hat gesagt: // Charles Henry wrote:
[metro 1] creates a bang each millisecond, approximately. The message rate is constrained by the block size, so you would want to put [metro 1] inside of a subpatch with [block~ 1] for best time resolution.
That's not true. Message rate is not related to the dsp vector size.
My mistake. I thought messages had to run in between dsp blocks.
Someone please refresh/adjust my memory... what IS the message rate in PD? I also thought it was related to block size all these years. And how can it be changed if needed?
There is no fixed rate, it's event-based with continuous time (or as continuous as floating point numbers gets you). But - it works with "logical" time, any relationship to "real" time is purely a coincidence.
Claude
http://claudiusmaximus.goto10.org
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Derek Holzer wrote:
Of course there's render mode....
downsample in pd patch- -> render to file via sfwrite~ or othe object --> upsample file with sndfile-convert or sound editor tool
should do the trick. Yes? At least to keep CPU limits from bottlenecking your render.
d.
The problem is rendering "faster than realtime", rendering "slower than realtime" is perfectly possible, I do it often.
Rendering faster than realtime isn't quite as simple as upsampling, you have to scale all clocks to match (like [metro], [delay], etc). Shouldn't be too difficult to hack Pd to work properly in this situation, as long as everything timing-centric adds events to the scheduler through the same mechanism.
Andy Farnell wrote:
On a closely related topic; Since Pd uses logical time why isn't there a "render mode" Csound style, for those occasions where you don't actually want to run in real time? Is it because blocking on unfinished output would leave no way for an object to notify that it had finished the computation?
Claude
Hallo, Charles Henry hat gesagt: // Charles Henry wrote:
Try it yourself with a phasor~-clone build from metro and vline~!
I see now. That works well up to 1000 Hz.
That's because [metro] is capped for periods smaller than 1 msec. If you drive the vline~ phasor clone with a self-made metro out of a looped [delay] object you can also go for higher frequencies.
Ciao
Frank Barknecht _ ______footils.org__
Miller Puckette wrote:
If I'm doing it right, single precision float should be able to represent latitude and longitude to within about two meters.
yes, a precision of 2m is just not enough for showing buildings or streets.
If more precision than that is needed, you'll want to use "tr" to change periods (as well as commas) into spaces so that you get lines like: -112 3348783983763 36 1514008468736 100 Then filter for whatever range of integer latitudes and longitudes you're actually looking at. Then you should get 1 degree x 2^-24, better than a centimeter.
ok, scaling turns out to be a crucial problem to solve for the project. (what details to show at which levels of scaling...) have to figure that out first... thnks, marius.
-
Andy Farnell -
Charles Henry -
chris clepper -
Claude Heiland-Allen -
Derek Holzer -
Frank Barknecht -
IOhannes m zmoelnig -
marius schebella -
Martin Peach -
Mathieu Bouchard -
Miller Puckette -
Spencer Russell -
Yvan Vander Sanden