[del 4m33s]
[1 3s( | [line]
[metro 1d2h4m3s21ms]
That last one is overkill. :) But sometimes you want to work in something other than ms, and it's a pain to make convenience abstractions. Kinda like [f $0]--[set $1-blah( is a pain
If a class with a float method that has no symbol method receives ([0-9]+[wdhms]+)+ then couldn't pd just convert it to a millisecond float value?
-Jonathan
Great suggestion. It makes sense. And numerical strings are already parsed for e (exponent) and - (minus) aren't they?
Andy
On Tue, Feb 14, 2012 at 10:10:54PM -0800, Jonathan Wilkes wrote:
[del 4m33s]
[1 3s( | [line]
[metro 1d2h4m3s21ms]
That last one is overkill. :) But sometimes you want to work in something other than ms, and it's a pain to make convenience abstractions. Kinda like [f $0]--[set $1-blah( is a pain
If a class with a float method that has no symbol method receives ([0-9]+[wdhms]+)+ then couldn't pd just convert it to a millisecond float value?
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Should be easy enough to implement since it would be a symbol, so it would be clearly separated from the currently arg, which is always a float.
.hc
On Feb 15, 2012, at 1:57 AM, Andy Farnell wrote:
Great suggestion. It makes sense. And numerical strings are already parsed for e (exponent) and - (minus) aren't they?
Andy
On Tue, Feb 14, 2012 at 10:10:54PM -0800, Jonathan Wilkes wrote:
[del 4m33s]
[1 3s( | [line]
[metro 1d2h4m3s21ms]
That last one is overkill. :) But sometimes you want to work in something other than ms, and it's a pain to make convenience abstractions. Kinda like [f $0]--[set $1-blah( is a pain
If a class with a float method that has no symbol method receives ([0-9]+[wdhms]+)+ then couldn't pd just convert it to a millisecond float value?
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
A better way might be to give the line~ (etc) objects optional arguments to specify units. I think there aren't many of them (line, line~, vline~, delay, metro, delread~, vd~). I also think that's how Max dealt with it.
In particular, it would be very useful to be able to specify a delay in samples or "blocks".
cheers Miller
On Wed, Feb 15, 2012 at 01:21:25PM -0500, Hans-Christoph Steiner wrote:
Should be easy enough to implement since it would be a symbol, so it would be clearly separated from the currently arg, which is always a float.
.hc
On Feb 15, 2012, at 1:57 AM, Andy Farnell wrote:
Great suggestion. It makes sense. And numerical strings are already parsed for e (exponent) and - (minus) aren't they?
Andy
On Tue, Feb 14, 2012 at 10:10:54PM -0800, Jonathan Wilkes wrote:
[del 4m33s]
[1 3s( | [line]
[metro 1d2h4m3s21ms]
That last one is overkill. :) But sometimes you want to work in something other than ms, and it's a pain to make convenience abstractions. Kinda like [f $0]--[set $1-blah( is a pain
If a class with a float method that has no symbol method receives ([0-9]+[wdhms]+)+ then couldn't pd just convert it to a millisecond float value?
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yes, blocks and samples would be great too.
The advantage of having a symbol qualifier in a message as opposed to creation arguments of the object is that [line~] etc could respond to mixed messages with different units.
Andy
On Wed, Feb 15, 2012 at 10:26:49AM -0800, Miller Puckette wrote:
A better way might be to give the line~ (etc) objects optional arguments to specify units. I think there aren't many of them (line, line~, vline~, delay, metro, delread~, vd~). I also think that's how Max dealt with it.
In particular, it would be very useful to be able to specify a delay in samples or "blocks".
cheers Miller
On Wed, Feb 15, 2012 at 01:21:25PM -0500, Hans-Christoph Steiner wrote:
Should be easy enough to implement since it would be a symbol, so it would be clearly separated from the currently arg, which is always a float.
.hc
On Feb 15, 2012, at 1:57 AM, Andy Farnell wrote:
Great suggestion. It makes sense. And numerical strings are already parsed for e (exponent) and - (minus) aren't they?
Andy
On Tue, Feb 14, 2012 at 10:10:54PM -0800, Jonathan Wilkes wrote:
[del 4m33s]
[1 3s( | [line]
[metro 1d2h4m3s21ms]
That last one is overkill. :) But sometimes you want to work in something other than ms, and it's a pain to make convenience abstractions. Kinda like [f $0]--[set $1-blah( is a pain
If a class with a float method that has no symbol method receives ([0-9]+[wdhms]+)+ then couldn't pd just convert it to a millisecond float value?
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-15 19:49, Andy Farnell wrote:
Yes, blocks and samples would be great too.
The advantage of having a symbol qualifier in a message as opposed to creation arguments of the object is that [line~] etc could respond to mixed messages with different units.
i think (iirc max correctly), miller meant an additional argument to the message rather than an additional creation argument to the object.
e.g. [0, 1 12 s( could ramp in 12secs, wherease [1, 0 12 d( would take considerably longer.
this is way easier to parse and i believe more foolproof than making an automagic parser that would make [12h(->[f]->[print] output "4.32e+07" rather than an error, which it really was because i accidentally hit "h" when trying to type 12.
fgmasr IOhannes
----- Original Message -----
From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-list@iem.at Cc: Sent: Wednesday, February 15, 2012 2:09 PM Subject: Re: [PD] specifying time
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-15 19:49, Andy Farnell wrote:
Yes, blocks and samples would be great too.
The advantage of having a symbol qualifier in a message as opposed to creation arguments of the object is that [line~] etc could respond to mixed messages with different units.
i think (iirc max correctly), miller meant an additional argument to the message rather than an additional creation argument to the object.
Right, that's how I understood it, too.
e.g. [0, 1 12 s( could ramp in 12secs, wherease [1, 0 12 d( would take considerably longer.
this is way easier to parse and i believe more foolproof than making an automagic parser that would make [12h(->[f]->[print] output "4.32e+07" rather than an error, which it really was because i accidentally hit "h" when trying to type 12.
What if I accidentally hit " h", or "1337"?
Also, it's way easier to parse because you're comparing apples to oranges. If you only want the ability to specify one unit at a time then it's trivial to parse 12s.
Automagic also means "you don't have to code a solution for every single class, including externals, that uses floats to mean milliseconds."
-Jonathan
fgmasr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk88AwEACgkQkX2Xpv6ydvTlTwCg8s7sfi17IerT1IY1oEVgE+24 AysAoNoVxigeyxl9X5k5hpBztlDrm7um =lDhe -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Automagic also means "you don't have to code a solution for every single class, including externals, that uses floats to mean milliseconds."
so what does your automagic parser make of "3m" then?
fgmadr IOhannes
----- Original Message -----
From: IOhannes m zmoelnig zmoelnig@iem.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Wednesday, February 15, 2012 2:47 PM Subject: Re: [PD] specifying time
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Automagic also means "you don't have to code a solution for
every single class, including
externals, that uses floats to mean milliseconds."
so what does your automagic parser make of "3m" then?
3 minutes.
fgmadr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk88C9MACgkQkX2Xpv6ydvQwUACfR9eR+Oz0zTXeUqaUJHuw1PCT BFoAoLosXBvIltxydCNbmDQmlhkC1/9i =Kc2D -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-15 20:50, Jonathan Wilkes wrote:
3 minutes.
darn, given that i wanted some distance, should i use the speed of light, of sound or my car to multiply with the time?
fgmar IOhannes
----- Original Message -----
From: IOhannes m zmoelnig zmoelnig@iem.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Wednesday, February 15, 2012 2:54 PM Subject: Re: [PD] specifying time
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-15 20:50, Jonathan Wilkes wrote:
3 minutes.
darn, given that i wanted some distance, should i use the speed of light, of sound or my car to multiply with the time?
Let's go back:
Instead of time units, let's take the incoming single-selector "pi" and replace it with the float value of pi for any object that doesn't have a "pi" method or an "anything" method (but does have a float method). Furthermore, if a class defines a float argument but the argument provided isn't a float, then check first if what it received was A_SYMBOL 'pi' and if so replace with the float value of pi.
Is what I wrote above possible to do without causing huge problems to performance or creating ambiguities? Is it something people would look at as a feature, or a nuisance that makes it harder to learn Pd? If the answer is that something like this constant expansion is a bad idea then there's no point discussing macro expansion for time units.
-Jonathan
fgmar IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk88DWYACgkQkX2Xpv6ydvRc5ACgtv6fVjriSSqnpodaIDImSM48 LkMAoIHJlWJ3RVSXBKQGY8R8AQFEc17x =ATle -----END PGP SIGNATURE-----
On 2012-02-15 16:11, Jonathan Wilkes wrote:
Let's go back:
Instead of time units, let's take the incoming single-selector "pi" and replace it with the float value of pi for any object that doesn't have a "pi" method or an "anything" method (but does have a float method). Furthermore, if a class defines a float argument but the argument provided isn't a float, then check first if what it received was A_SYMBOL 'pi' and if so replace with the float value of pi.
Is what I wrote above possible to do without causing huge problems to performance or creating ambiguities? Is it something people would look at as a feature, or a nuisance that makes it harder to learn Pd? If the answer is that something like this constant expansion is a bad idea then there's no point discussing macro expansion for time units.
-Jonathan
I think it's a bad idea to make assumptions like that. It would be far better to interpose a filter when needed. I attach a pdlua script [str2ms] that will output a float millisecond value given some kind of string specifying time. It's very easy to extend to other time types and only needs to be used if you want it, not like some secret apple troll lurking inside the object that "knows" what I want.
Martin
----- Original Message -----
From: Martin Peach martin.peach@sympatico.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: IOhannes m zmoelnig zmoelnig@iem.at; "pd-list@iem.at" pd-list@iem.at Sent: Wednesday, February 15, 2012 4:49 PM Subject: Re: [PD] constants
On 2012-02-15 16:11, Jonathan Wilkes wrote:
Let's go back:
Instead of time units, let's take the incoming single-selector
"pi" and replace it with
the float value of pi for any object that doesn't have a "pi"
method or an
"anything" method (but does have a float method). Furthermore,
if a class defines a
float argument but the argument provided isn't a float, then check
first if what it received
was A_SYMBOL 'pi' and if so replace with the float value of pi.
Is what I wrote above possible to do without causing huge problems to
performance or
creating ambiguities? Is it something people would look at as a feature,
or a nuisance that
makes it harder to learn Pd? If the answer is that something like this
constant expansion
is a bad idea then there's no point discussing macro expansion for time
units.
-Jonathan
I think it's a bad idea to make assumptions like that. It would be far better to interpose a filter when needed. I attach a pdlua script [str2ms] that will output a float millisecond value given some kind of string specifying time. It's very easy to extend to other time types and only needs to be used if you want it, not like some secret apple troll lurking inside the object that "knows" what I want.
But "what you want" in this case is necessarily always an error to the console, without the possibility of doing something else instead.
Is there a way to give the user an option of what happens, like: [badarg pi 3.14...] <-- if the bad arg is "pi" substitute 3.14... and create the object
-Jonathan
Martin
On 02/15/12 23:47, Jonathan Wilkes wrote:
Is there a way to give the user an option of what happens, like: [badarg pi 3.14...]<-- if the bad arg is "pi" substitute 3.14... and create the object
there is [try] in iemguts, which does something like this, though iirc it (currently) doesn't work with abstractions, which makes it a bit limited.
fgmadrs IOhannes
----- Original Message -----
From: IOhannes m zmölnig zmoelnig@iem.at To: pd-list@iem.at Cc: Sent: Thursday, February 16, 2012 7:42 AM Subject: Re: [PD] constants
On 02/15/12 23:47, Jonathan Wilkes wrote:
Is there a way to give the user an option of what happens, like: [badarg pi 3.14...]<-- if the bad arg is "pi" substitute
3.14... and create the object
there is [try] in iemguts, which does something like this, though iirc it (currently) doesn't work with abstractions, which makes it a bit limited.
Thanks, I'll have a look.
-Jonathan
fgmadrs IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2012-02-15 16:11, Jonathan Wilkes wrote:
Let's go back:
Instead of time units, let's take the incoming single-selector "pi" and replace it with the float value of pi for any object that doesn't have a "pi" method or an "anything" method (but does have a float method). Furthermore, if a class defines a float argument but the argument provided isn't a float, then check first if what it received was A_SYMBOL 'pi' and if so replace with the float value of pi.
Is what I wrote above possible to do without causing huge problems to performance or creating ambiguities? Is it something people would look at as a feature, or a nuisance that makes it harder to learn Pd? If the answer is that something like this constant expansion is a bad idea then there's no point discussing macro expansion for time units.
-Jonathan
You could easily add a creator function for [pi] which becomes a float with initial value 3.14--and add a method to [f] for the message [ pi (
Still a little cumbersome to use because this doesn't get replacement in messages, arguments or anywhere else--but consistent with patching styles for symbols/floats.
Le 2012-02-15 à 13:11:00, Jonathan Wilkes a écrit :
Instead of time units, let's take the incoming single-selector "pi" and replace it with the float value of pi for any object that doesn't have a "pi" method or an "anything" method (but does have a float method). Furthermore, if a class defines a float argument but the argument provided isn't a float, then check first if what it received was A_SYMBOL 'pi' and if so replace with the float value of pi. Is what I wrote above possible to do without causing huge problems to performance or creating ambiguities?
Compared to any code that checks whether something is A_FLOAT or not, and branches accordingly, it makes absolutely no speed difference for the case of A_FLOAT.
And for the other case... the difference is that if you rely on A_SYMBOL from being a type completely separate from A_FLOAT, for any reason, then you're toasted. It's actually the same issue as the auto-convert discussion from a while ago in which the symbol \123 would be regarded as float 123 if you look at it this way, or as symbol \123 if you look at it this way.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On 2012-02-16 13:39, Mathieu Bouchard wrote:
Le 2012-02-15 à 13:11:00, Jonathan Wilkes a écrit :
Instead of time units, let's take the incoming single-selector "pi" and replace it with the float value of pi for any object that doesn't have a "pi" method or an "anything" method (but does have a float method). Furthermore, if a class defines a float argument but the argument provided isn't a float, then check first if what it received was A_SYMBOL 'pi' and if so replace with the float value of pi. Is what I wrote above possible to do without causing huge problems to performance or creating ambiguities?
Compared to any code that checks whether something is A_FLOAT or not, and branches accordingly, it makes absolutely no speed difference for the case of A_FLOAT.
And for the other case... the difference is that if you rely on A_SYMBOL from being a type completely separate from A_FLOAT, for any reason, then you're toasted. It's actually the same issue as the auto-convert discussion from a while ago in which the symbol \123 would be regarded as float 123 if you look at it this way, or as symbol \123 if you look at it this way.
That's why I think it's better to insert filter objects in front of just the appropriate objects, to prevent unintended conversions and not waste time checking to see if something might be convertible for no reason. IMHO pdlua is really good for symbol parsing, as it doesn't use the symbol table, and the script can be edited without needing to compile it, and it's just easier to manipulate strings in lua.
Martin
----- Original Message -----
From: Martin Peach martin.peach@sympatico.ca To: Mathieu Bouchard matju@artengine.ca Cc: Jonathan Wilkes jancsika@yahoo.com; "pd-list@iem.at" pd-list@iem.at; IOhannes m zmoelnig zmoelnig@iem.at Sent: Thursday, February 16, 2012 1:58 PM Subject: Re: [PD] constants
On 2012-02-16 13:39, Mathieu Bouchard wrote:
Le 2012-02-15 à 13:11:00, Jonathan Wilkes a écrit :
Instead of time units, let's take the incoming single-selector
"pi"
and replace it with the float value of pi for any object that
doesn't
have a "pi" method or an "anything" method (but
does have a float
method). Furthermore, if a class defines a float argument but the argument provided isn't a float, then check first if what it
received
was A_SYMBOL 'pi' and if so replace with the float value of pi.
Is
what I wrote above possible to do without causing huge problems to performance or creating ambiguities?
Compared to any code that checks whether something is A_FLOAT or not, and branches accordingly, it makes absolutely no speed difference for the case of A_FLOAT.
And for the other case... the difference is that if you rely on A_SYMBOL from being a type completely separate from A_FLOAT, for any reason, then you're toasted. It's actually the same issue as the auto-convert discussion from a while ago in which the symbol \123 would be regarded as float 123 if you look at it this way, or as symbol \123 if you look at it this way.
But, for example, [route float pi] would still work the same because [route] has an anything method defined and takes A_GIMME. So the problem would be limited to users who need to rely on objects that don't have a method for anythings or, specifically, don't have a method for "pi", or take float arguments. And by 'rely' I mean they _need_ the object to give them an error in order for the patch to work correctly, so that would be typos and runtime errors when you're sending one of a subset of anythings to a float processing object or signal object.
-Jonathan
That's why I think it's better to insert filter objects in front of just the appropriate objects, to prevent unintended conversions and not waste time checking to see if something might be convertible for no reason. IMHO pdlua is really good for symbol parsing, as it doesn't use the symbol table, and the script can be edited without needing to compile it, and it's just easier to manipulate strings in lua.
Martin
Le 2012-02-15 à 20:54:00, IOhannes m zmoelnig a écrit :
darn, given that i wanted some distance, should i use the speed of light, of sound or my car to multiply with the time?
Because Miller is the measure of all things, let's use the speed of Miller's rotation around the Earth when Miller is resting in its ground state, which is roughly 40075017 metres * cos(32.7⁰) / 86400 s/day = 390.318 metres per second.
Or 0.390318 metre per ms.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On 02/16/12 19:33, Mathieu Bouchard wrote:
Le 2012-02-15 à 20:54:00, IOhannes m zmoelnig a écrit :
darn, given that i wanted some distance, should i use the speed of light, of sound or my car to multiply with the time?
Because Miller is the measure of all things, let's use the speed of Miller's rotation around the Earth when Miller is resting in its ground state, which is roughly 40075017 metres * cos(32.7⁰) / 86400 s/day = 390.318 metres per second.
thanks for clarification. is there any relation to the speed of sound near boiling water?
fgmasdr IOhannes
Le 2012-02-16 à 19:41:00, IOhannes m zmölnig a écrit :
On 02/16/12 19:33, Mathieu Bouchard wrote:
Le 2012-02-15 à 20:54:00, IOhannes m zmoelnig a écrit :
darn, given that i wanted some distance, should i use the speed of light, of sound or my car to multiply with the time?
Because Miller is the measure of all things, let's use the speed of Miller's rotation around the Earth when Miller is resting in its ground state, which is roughly 40075017 metres * cos(32.7⁰) / 86400 s/day = 390.318 metres per second.
thanks for clarification. is there any relation to the speed of sound near boiling water?
Only during teatime.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: Hans-Christoph Steiner hans@at.or.at Cc: "pd-list@iem.at" pd-list@iem.at Sent: Wednesday, February 15, 2012 1:26 PM Subject: Re: [PD] specifying time
A better way might be to give the line~ (etc) objects optional arguments to specify units. I think there aren't many of them (line, line~, vline~, delay, metro, delread~, vd~). I also think that's how Max dealt with it.
In particular, it would be very useful to be able to specify a delay in samples or "blocks".
Could you just convert to ms, or would this require changes to the code in order to be sufficiently precise?
-Jonathan
cheers Miller
On Wed, Feb 15, 2012 at 01:21:25PM -0500, Hans-Christoph Steiner wrote:
Should be easy enough to implement since it would be a symbol, so it would
be clearly separated from the currently arg, which is always a float.
.hc
On Feb 15, 2012, at 1:57 AM, Andy Farnell wrote:
Great suggestion. It makes sense. And numerical strings are already parsed for e (exponent) and - (minus) aren't they?
Andy
On Tue, Feb 14, 2012 at 10:10:54PM -0800, Jonathan Wilkes wrote:
[del 4m33s]
[1 3s( | [line]
[metro 1d2h4m3s21ms]
That last one is overkill. :) But sometimes you want to work in something other than ms, and
it's a pain to make convenience abstractions.
Kinda like [f $0]--[set $1-blah( is a pain
If a class with a float method that has no symbol method receives
([0-9]+[wdhms]+)+
then couldn't pd just convert it to a millisecond float value?
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
I spent 33 years and four months in active military service and during that
period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
That's an open question; I'm not sure whether computing the length of a blockin msec and then sending it to "delay", for instance, would always round back to the exact number of Pd ticks in a block. (A pd tick, internally, is small enough that one millisecond and one sample both are integer numbers of ticks, at least provided the SR is one of the "standard" ones.)
There would still be the problem of round-off errors for larger delays - the only way I can see to manage that is to have the time objects have a notion of unit.
To respond to another part of the thread, I'd suggest trying to do it the way Max does (but I haven't cranked up Max in some time and haven't any idea how that goes), and anyway, there should be a way to specify the units both in creation arguments and in incoming messages.
I think "seconds" "milliseconds/msec/ms" "samples" and "blocks" would be adequate, but someone else might want to be able to sync to external or cariable clocks - I don't know if that's worth putting in or not.
cheers Miller
On Wed, Feb 15, 2012 at 11:48:29AM -0800, Jonathan Wilkes wrote:
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: Hans-Christoph Steiner hans@at.or.at Cc: "pd-list@iem.at" pd-list@iem.at Sent: Wednesday, February 15, 2012 1:26 PM Subject: Re: [PD] specifying time
A better way might be to give the line~ (etc) objects optional arguments to specify units. I think there aren't many of them (line, line~, vline~, delay, metro, delread~, vd~). I also think that's how Max dealt with it.
In particular, it would be very useful to be able to specify a delay in samples or "blocks".
Could you just convert to ms, or would this require changes to the code in order to be sufficiently precise?
-Jonathan
cheers Miller
On Wed, Feb 15, 2012 at 01:21:25PM -0500, Hans-Christoph Steiner wrote:
Should be easy enough to implement since it would be a symbol, so it would
be clearly separated from the currently arg, which is always a float.
.hc
On Feb 15, 2012, at 1:57 AM, Andy Farnell wrote:
Great suggestion. It makes sense. And numerical strings are already parsed for e (exponent) and - (minus) aren't they?
Andy
On Tue, Feb 14, 2012 at 10:10:54PM -0800, Jonathan Wilkes wrote:
[del 4m33s]
[1 3s( | [line]
[metro 1d2h4m3s21ms]
That last one is overkill. :) But sometimes you want to work in something other than ms, and
it's a pain to make convenience abstractions.
Kinda like [f $0]--[set $1-blah( is a pain
If a class with a float method that has no symbol method receives
([0-9]+[wdhms]+)+
then couldn't pd just convert it to a millisecond float value?
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
I spent 33 years and four months in active military service and during that
period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers.   - General Smedley Butler
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 2012-02-15 à 12:07:00, Miller Puckette a écrit :
That's an open question; I'm not sure whether computing the length of a blockin msec and then sending it to "delay", for instance, would always round back to the exact number of Pd ticks in a block.
It depends on how you do it. See attached patch to see that [int] helps find a lot of cases of (1/x)*x = 0.999999... But there are less than how I think there would be.
If replacing truncation by actual rounding, then the problem disappears.
C's (int) and C++'s int() are the same as Pd's [int].
(A pd tick, internally, is small enough that one millisecond and one sample both are integer numbers of ticks, at least provided the SR is one of the "standard" ones.)
That's actually the ppcm of 192 and 88,2 kHz.
There would still be the problem of round-off errors for larger delays - the only way I can see to manage that is to have the time objects have a notion of unit.
Would a similar things happen to all objects that take frequencies ?
[osc~ 4 kHz] means 4000
[osc~ 1382.3 rad/s] means 220
[osc~ 36000 deg/s] means 100
[osc~ 2 ms] means 500
[osc~ 69 midi] means 440
[osc~ 180 bpm] means 3
and don't forget barks...
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2012-02-15 à 06:57:00, Andy Farnell a écrit :
On Tue, Feb 14, 2012 at 10:10:54PM -0800, Jonathan Wilkes wrote:
If a class with a float method that has no symbol method receives ([0-9]+[wdhms]+)+ then couldn't pd just convert it to a millisecond float value?
Great suggestion. It makes sense. And numerical strings are already parsed for e (exponent) and - (minus) aren't they?
e+- are parsed because they are related to the float format itself.
float format doesn't imply milliseconds, far from it.
[osc~] and [lop~] use hertz as their implicit unit. What would [osc~ 0.1s] mean, and how would the parser know which one should be which ?
[rpole~]'s units are in radians (that is, rad/s of cutoff per Hz of sampling rate).
[mtof]'s units are midi frequencies... and the number has to come from outside of the box. The originating messagebox (or whatever else) has no idea that it's going towards [mtof].
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-
Andy Farnell -
Charles Henry -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jonathan Wilkes -
Martin Peach -
Mathieu Bouchard -
Miller Puckette