Hi Miller,

On Tue, Aug 02, 2011 at 09:35:14PM -0700, Miller Puckette wrote:

Nope... there needs to be a string-to-binary-list-and-back function somewhere but I can't figure out what to name it :)

Would you consider adding a more generally useful [split] object to Pd for this type of thing? Something like this is present in Perl, Python, Javascript, etc. It has two inlets and one argument. The right inlet and argument both specify the character or sequence of characters (symbol) to split the incoming symbol on. The left inlet accepts a symbol and the single outlet outputs a list, which is the symbol that came in, split into a list of atoms using the specified character or symbol as a divider.

On Wed, Aug 03, 2011 at 01:26:21AM -0300, Alexandre Torres Porres wrote:

...

now, some files come in ratios as one symbol like this

5/4 3/2 7/4

Here you would use [split /] and filter those atoms like "5/4" through to get lists like "5 4".

This would make a whole bunch of behaviour possible in Pd that is currently only possible with externals.

Hm, I should just contribute a patch.

Cheers,

Chris.

http://mccormick.cx

On Wed, Aug 03, 2011 at 09:34:50AM +0200, IOhannes m zmoelnig wrote:

On 2011-08-03 08:21, Chris McCormick wrote:

...

Hm, I should just contribute a patch.

you could also just take the code of zexy's [symbol2list] object. it does exactly what you describe.

PS: i hereby grant miller s. puckette (the authore of pure-data) the right to use (and modify) the code of zexy's "symbol2list" objectn to integrate it into puredata under the terms of the revised BSD license under which puredata is currently distributed.

What do you reckon, Miller? Would it help if I did the aforementioned work of integrating it and submitting a nice clean patch with helpfile and all?

Heck, I will just do it and see.

Chris.

http://mccormick.cx

On Wed, 3 Aug 2011 14:21:09 +0800 Chris McCormick chris@mccormick.cx wrote:

Would you consider adding a more generally useful [split] object

I agree this would be a useful core object.

What problems, if any, do you forsee?

Would those outputs implicitly be symbols? Or would we venture the types in advance like

[split f / f]

to obtain two floats

Turning the symbol 5/7 to a real number would then be

[symbol 5/7( | [split f / f] | / [/ ] | [number 0.714285]

On Wed, 3 Aug 2011 17:12:49 -0400 Hans-Christoph Steiner hans@at.or.at wrote:

On Aug 3, 2011, at 3:29 PM, Andy Farnell wrote:

...

On Wed, 3 Aug 2011 14:21:09 +0800 Chris McCormick chris@mccormick.cx wrote:

...

Would you consider adding a more generally useful [split] object

I agree this would be a useful core object.

What problems, if any, do you forsee?

Would those outputs implicitly be symbols? Or would we venture the types in advance like

[split f / f]

to obtain two floats

Turning the symbol 5/7 to a real number would then be

[symbol 5/7( | [split f / f] | / [/ ] | [number 0.714285]

I think to fit with the Pd type system in general, it should
automatically interpret things into floats and symbols (http://puredata.info/dev/PdDefinitions ):

Pd Manual 2.1.2

"The text is divided into atoms separated by white space."

"Atoms are either numbers or symbols like '+'. "

Pd Manual 2.1.2

"Anything that is not a valid number is considered a symbol."

That seems unambiguous. So I guess if you wanted your "numbers" as symbols, you'd explicitly convert them back to symbols.

I used to use [symbol2list] a lot, so Iohannes suggestion is interesting. But could that split on an arbitary symbol like Chris suggests for the proposed [split] ?

a.

belated response...

how about 'list tosymbol' and 'list fromsymbol'? I.e.

98 97 116 -> bat -> 98 97 116 On Wed, Aug 03, 2011 at 10:45:24PM +0100, Andy Farnell wrote:

On Wed, 3 Aug 2011 17:12:49 -0400 Hans-Christoph Steiner hans@at.or.at wrote:

...

On Aug 3, 2011, at 3:29 PM, Andy Farnell wrote:

...

On Wed, 3 Aug 2011 14:21:09 +0800 Chris McCormick chris@mccormick.cx wrote:

...

Would you consider adding a more generally useful [split] object

I agree this would be a useful core object.

What problems, if any, do you forsee?

Would those outputs implicitly be symbols? Or would we venture the types in advance like

[split f / f]

to obtain two floats

Turning the symbol 5/7 to a real number would then be

[symbol 5/7( | [split f / f] | / [/ ] | [number 0.714285]

I think to fit with the Pd type system in general, it should
automatically interpret things into floats and symbols (http://puredata.info/dev/PdDefinitions ):

Pd Manual 2.1.2

"The text is divided into atoms separated by white space."

"Atoms are either numbers or symbols like '+'. "

Pd Manual 2.1.2

"Anything that is not a valid number is considered a symbol."

That seems unambiguous. So I guess if you wanted your "numbers" as symbols, you'd explicitly convert them back to symbols.

I used to use [symbol2list] a lot, so Iohannes suggestion is interesting. But could that split on an arbitary symbol like Chris suggests for the proposed [split] ?

a.

-- Andy Farnell padawan12@obiwannabe.co.uk

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On Wed, Aug 31, 2011 at 08:46:54AM +0800, Chris McCormick wrote:

Hi Miller,

On Tue, Aug 30, 2011 at 01:21:29PM -0700, Miller Puckette wrote:

...

belated response...

how about 'list tosymbol' and 'list fromsymbol'? I.e.

98 97 116 -> bat -> 98 97 116

I don't think this would accomodate the same use-cases as zexy's [symbol2list] or the hypothetical [split]. It doesn't really help in the original ratio-parsing case which started this thread.

I was thinking more of:

(symbol) "this/is/my/path/symbol.txt" -> (list) "this" "is" "my" "path" "symbol.txt" -> (symbol) "this/is/my/path/symbol.txt"

Or in the ratios case cited:

"2/3" -> "2" "3" -> "2/3"

This would give it a great deal of general usefulness.

I am in favour of having that functionality as part of [list] and those names look good to me. For the functionality you describe maybe something like [list ascii2symbol] and [list symbol2ascii]? Those would also be pretty useful!

I am currently making a [split] abstraction based on Jamie's work. I will send it through when I am done - or you can just look at symbol2list's source which IOhannes has re-licensed in a message to this list for use in Pd:

hmm... another possibility, as in lisp: "list explode" and "list implode" ?

My idea is that, once this is in Pd vanilla, the "2/3" -> "2" "3" type of split is easy enough to program in an abstraction, but it's presently not possible at all; meanwhile, the funtionality I'm describing is pretty canonical and hard to split up into finer components in any way I can see.

cheers Miller

On Tue, Aug 30, 2011 at 11:19:46PM -0700, Miller Puckette wrote:

...

I am in favour of having that functionality as part of [list] and those names look good to me. For the functionality you describe maybe something like [list ascii2symbol] and [list symbol2ascii]? Those would also be pretty useful!

I am currently making a [split] abstraction based on Jamie's work. I will send it through when I am done - or you can just look at symbol2list's source which IOhannes has re-licensed in a message to this list for use in Pd:

hmm... another possibility, as in lisp: "list explode" and "list implode" ?

Also good!

My idea is that, once this is in Pd vanilla, the "2/3" -> "2" "3" type of split is easy enough to program in an abstraction, but it's presently not possible at all; meanwhile, the funtionality I'm describing is pretty canonical and hard to split up into finer components in any way I can see.

Ah, ok, so you could do:

bat/cat/rat -> 98 97 116 47 99 97 116 47 114 97 116

and then you would run through the number list finding 47 ("/") and re-building the separate symbols using the reverse operation.

I guess this would be cool because it would also allow you to store proper strings with all kinds of characters in regular Pd arrays, which might be fun. Hmmm, also many other things!

easy enough to program in an abstraction, but it's presently not possible at all;

After looking at Jonathan's ratio splitting abstraction I think this might actually be possible with [makefilename] madness, but it's much uglier than what you propose: http://lists.puredata.info/pipermail/pd-list/2011-08/090196.html

Cheers,

Chris.

http://mccormick.cx

On Wed, 31 Aug 2011, Jonathan Wilkes wrote:

Keep in mind that [list implode] must be smart enough to output the float atom "12" given the input "49 50".  If it gives you "symbol 12" then your back to the [makefilename] madness from my original vanilla solution.

It's not that simple. People might not want always a cast to float, because then, it might destroy part of the information in the symbol.

see : http://lists.puredata.info/pipermail/pd-list/2006-09/042419.html

that's how [gf/s2l] is different : it outputs only symbols. I think I could make it an option, but I wouldn't know how to call it. E.g. :

[gf/s2l /, docast] [gf/s2l /, convert] [gf/s2l /, atof]

where the name after the comma is an attribute method taking one optional float arg defaulting to 1, just like all other flags in GF, defined like this :

\attr bool docast;

void cast_if_wanted (t_atom *foo) {if (docast) ........;}

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

On 2011-09-03 22:47, Jonathan Wilkes wrote:

----- Original Message -----

...

From: Mathieu Bouchardmatju@artengine.ca To: Jonathan Wilkesjancsika@yahoo.com Cc: Chris McCormickchris@mccormick.cx; Miller Puckettemsp@ucsd.edu; "pd-list@iem.at"pd-list@iem.at Sent: Saturday, September 3, 2011 1:20 PM Subject: Re: [PD] (breaking symbols) was Re: find a list of numbers in a text file

On Wed, 31 Aug 2011, Jonathan Wilkes wrote:

...

Keep in mind that [list implode] must be smart enough to output the float atom "12" given the input "49 50". If it gives you

"symbol 12" then your

...

back to the [makefilename] madness from my original vanilla solution.

It's not that simple.

It needs to be that simple for the general case because Pd Vanilla has no (sensible) mechanism to convert a symbol atom into a float.

If symbol atoms which look like numbers to the naked eye are going to start flying around more freely in Pd then the docs need to explain how atoms are a kind of weird file cabinet where the label on the cabinet tells you which file-folder inside actually holds the data. So if you send the symbol-atom "15" to [max], the file clerk will complain because it's looking for a number but the label on the cabinet says "A_SYMBOL". (Additionally, if you tell the clerk to ignore the label and just pull out a number, the clerk will look in "A_FLOAT" and give you a "0", because the "15" is in the "A_SYMBOL" file-folder.)

Hm... is there a way you can tell the clerk to be a real go-getter when looking for a float atom inside a cabined labeled "A_SYMBOL" by just going ahead and seeing if the data in the "A_SYMBOL" file-folder looks like a number, and if so convert it to a float and send it on its way?

Any external can do that easily enough if it wants to by using sscanf with a format string:

int symbol_to_float (t_atom *atom, t_float *afloat) { int n; n = sscanf(atom->a_w.w_symbol->s_name, "%f", afloat); return n; /* afloat is valid if n is 1 */ }

But there are more ways of writing numbers than a single sscanf call can handle, so a real version would have to check all the expected input styles.

The function pd_defaultsymbol in m_class.c is the default symbol handler for objects that have no explicit symbol method. It could check to see if a non-default float method exists and if so try to convert the symbol to a float for the float method to eat.

Martin

----- Original Message -----

From: Martin Peach martin.peach@sympatico.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Mathieu Bouchard matju@artengine.ca; "pd-list@iem.at" pd-list@iem.at; Chris McCormick chris@mccormick.cx; Miller Puckette msp@ucsd.edu Sent: Sunday, September 4, 2011 1:10 AM Subject: Re: [PD] (breaking symbols) was Re: find a list of numbers in a text file

On 2011-09-03 22:47, Jonathan Wilkes wrote:

...

----- Original Message -----

...

From: Mathieu Bouchardmatju@artengine.ca To: Jonathan Wilkesjancsika@yahoo.com Cc: Chris McCormickchris@mccormick.cx; Miller

Puckettemsp@ucsd.edu; "pd-list@iem.at"pd-list@iem.at

...

...

Sent: Saturday, September 3, 2011 1:20 PM Subject: Re: [PD] (breaking symbols) was Re: find a list of numbers in

a text file

...

...

On Wed, 31 Aug 2011, Jonathan Wilkes wrote:

...

Keep in mind that [list implode] must be smart enough to output

the float

...

...

...

atom "12" given the input "49 50".  If it

gives you

...

...

"symbol 12" then your

...

back to the [makefilename] madness from my original vanilla

solution.

...

...

It's not that simple.

It needs to be that simple for the general case because Pd Vanilla has no

(sensible) mechanism to convert

...

a symbol atom into a float.

If symbol atoms which look like numbers to the naked eye are going to start

flying around more freely in Pd

...

then the docs need to explain how atoms are a kind of weird file cabinet

where the label on the cabinet tells

...

you which file-folder inside actually holds the data.  So if you send the

symbol-atom "15" to [max], the file clerk will

...

complain because it's looking for a number but the label on the cabinet

says "A_SYMBOL".  (Additionally, if you tell

...

the clerk to ignore the label and just pull out a number, the clerk will

look in "A_FLOAT" and give you a "0", because

...

the "15" is in the "A_SYMBOL" file-folder.)

Hm... is there a way you can tell the clerk to be a real go-getter when

looking for a float atom inside a

...

cabined labeled "A_SYMBOL" by just going ahead and seeing if the

data in the "A_SYMBOL" file-folder looks like a

...

number, and if so convert it to a float and send it on its way?

Any external can do that easily enough if it wants to by using sscanf with a format string:

int symbol_to_float (t_atom *atom, t_float *afloat) {     int n;         n = sscanf(atom->a_w.w_symbol->s_name, "%f", afloat);         return n; /* afloat is valid if n is 1 */ }

But there are more ways of writing numbers than a single sscanf call can handle, so a real version would have to check all the expected input styles.

The function pd_defaultsymbol in m_class.c is the default symbol handler for objects that have no explicit symbol method. It could check to see if a non-default float method exists and if so try to convert the symbol to a float for the float method to eat.

Right-- at that point it's already just going to output an error anyway.

Martin

On Sun, 4 Sep 2011, Mathieu Bouchard wrote:

On Sat, 3 Sep 2011, Jonathan Wilkes wrote:

...

Also, I'm assuming [list implode] would accept and process a list at the left inlet, unlike [s2l] (which passes the 1st element to the right inlet).

I don't understand. Wouldn't [list implode] correspond to [l2s], whereas [list explode] would correspond to [s2l].

Damn. This was meant to end using a question mark, of course.

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

On Sep 4, 2011, at 2:01 PM, Jonathan Wilkes wrote:

----- Original Message -----

...

From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Chris McCormick chris@mccormick.cx; Miller Puckette <msp@ucsd.edu

...

; "pd-list@iem.at" pd-list@iem.at

Sent: Sunday, September 4, 2011 1:48 PM Subject: Re: [PD] (breaking symbols) was Re: find a list of numbers
in a text file

On Sat, 3 Sep 2011, Jonathan Wilkes wrote:

...

It needs to be that simple for the general case because Pd Vanilla
has no

(sensible) mechanism to convert a symbol atom into a float.

Then it needs a sensible mechanism to convert a symbol atom into a
float.

Yes, it does. But if there were one, it'd still be nice to have the
default be float atoms come out, and maybe a flag or a different creator name for
outputting all symbols. (Like [symbol explode]?)

Its more than just methods for converting, there needs to be a type
system which includes the possibility that "43" can be a symbol. Pd's
type system is meant to be "anything that can be intepreted as a
number is a float, everything else is a symbol". See this for
definitions: http://puredata.info/dev/PdDefinitions

So given that is the type system, how do you represent "43" as a
symbol? No matter the techniques for converting anything to a symbol,
it'll remain confusing to use these symbols unless this is resolved.

One possibility is to do a more duck-typing approach. For something
that accepts only symbols, it'll happily accept "43" as a symbol. For
something that only accept floats, it'll convert the symbol "43" to 43
and accept it as a float. The question here is how to handle it when
something expects both floats and symbols. As far as implementing
this, we could add to the t_symbol struct a flag to say whether it can
be read as a float, and store the float value there too.

This would open the door to making arbitrary symbol making really
easy, something like:

[symbol 43(

or

[symbol 43]

.hc

...

...

If symbol atoms which look like numbers to the naked eye are going
to start

flying around more freely in Pd then the docs need to explain how
atoms are a kind of weird file cabinet where the label on the cabinet tells you
which file-folder inside actually holds the data.

That's called a union or a variant record type or an «any» type or a sum-type or whatever else.

If it looks weird and/or difficult, it's because it's not taught in a way that makes it understood as normal.

I think the problem is it's not explicitly taught at all.

...

...

Also, I'm assuming [list implode] would accept and process a list at

the left inlet, unlike [s2l] (which passes the 1st element to the
right inlet).

I don't understand. Wouldn't [list implode] correspond to [l2s],
whereas [list explode] would correspond to [s2l].

That's right, I wrote the wrong one. I have a bad habit of getting
opposites mixed up-- if I'm not careful I'll create a [max] to output the
greater of two numbers.

...

---

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray,
Montréal, QC

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore

On Sep 4, 2011, at 4:55 PM, Mathieu Bouchard wrote:

On Sun, 4 Sep 2011, Hans-Christoph Steiner wrote:

...

One possibility is to do a more duck-typing approach. For
something that accepts only symbols, it'll happily accept "43" as a
symbol. For something that only accept floats, it'll convert the
symbol "43" to 43 and accept it as a float. The question here is
how to handle it when something expects both floats and symbols.
As far as implementing this, we could add to the t_symbol struct a
flag to say whether it can be read as a float, and store the float
value there too.

Duck-typing isn't about conversions...

Duck-typing is that a float-like thing is anything that «behaves» as
a float. Thus, for any atom-type that could be considered float- like, there needs to be a set of functions that apply to any float- like thing.

The term Duck-typing was invented to talk about certain cases of
hiding the implementation of something, especially the idea that
inheritance and type-checking don't matter as long as the type you
want to use has the appropriate functions attached to it.

The duck-typing term only applies to things for which you can attach
functions (methods) to types. Thus it can apply to pd objects, but
not to pd atoms... t_atomtype isn't similar to t_class... there are
no tables of functions to be used for different situations on
different atomtypes.

http://en.wikipedia.org/wiki/Duck_typing

In Pd, duck-typing happens with the "dsp" and "loadbang" methods, in
which from the standpoint of pd, a dsp-object is any object that has
a dsp-method, and a loadbang-object is any object that has a
loadbang-method, without any further declarations that might
explicitly mean « this class is in the DSPObject (or Loadbangable)
category » or anything similar.

I think you are missing the point of what I am saying. I am not
saying with we implement a strict duck typing mimicing Ruby or
Python. I am saying we can be inspired by that. Pd is not OOP, so
trying to force it into an OOP structure does not make sense.

So in the sense of Pd, anything that can be intepreted as a number
should be. But that's in conflict with having symbols that have
things that can be intepreted as a number. So make Pd consistent,
either it needs to be illegal to have symbols that can be interpreted
as a number, or maybe symbols that can be interpreted as a number
behave like a float when something is expecting a float.

.hc

Programs should be written for people to read, and only incidentally
for machines to execute.

• from Structure and Interpretation of Computer Programs

On Sep 5, 2011, at 1:11 PM, Mathieu Bouchard wrote:

On Sun, 4 Sep 2011, Hans-Christoph Steiner wrote:

...

I think you are missing the point of what I am saying. I am not
saying with we implement a strict duck typing mimicing Ruby or
Python.

I think you are missing the point of what I am saying. I am saying
that you are using the wrong words for that.

Unfortunately terms to describe typing do not have clear boundaries.
But which words are used are not important to me, as long as the
meaning gets across. Does "dynamic typing" make you happy? Python,
Ruby, Perl, Tcl, and to a large extent Pd, all have "dynamic typing".

...

So in the sense of Pd, anything that can be intepreted as a number
should be. But that's in conflict with having symbols that have
things that can be intepreted as a number. So make Pd consistent,
either it needs to be illegal to have symbols that can be
interpreted as a number,

This could break some existing patches.

Do you have an examples? That would be very helpful. Off the top of
my head, it seems that it would only break patches that rely on
errors, which is not a very common situation.

hc

...

or maybe symbols that can be interpreted as a number behave like a
float when something is expecting a float.

That's what Tcl and Perl do for ints, floats and strings.

They don't call it duck-typing though, and no-one does.

---

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray,
Montréal, QC

"[T]he greatest purveyor of violence in the world today [is] my own
government." - Martin Luther King, Jr.

On Sep 5, 2011, at 2:06 PM, Frank Barknecht wrote:

On Mon, Sep 05, 2011 at 01:36:34PM -0400, Hans-Christoph Steiner
wrote:

...

On Sep 5, 2011, at 1:11 PM, Mathieu Bouchard wrote:

...

On Sun, 4 Sep 2011, Hans-Christoph Steiner wrote:

...

So in the sense of Pd, anything that can be intepreted as a number should be.

This discussion is soooo 2005 ...

And sadly is still unresolved...

Anyway, a symbol, even if it consists only of digits, will not be interpreted as a number in Pd: a symbol is a symbol, a float is a
float. Note that the sentence that you quote sometimes and which sounds
similar to the statement above ("Anything that is not a valid number os [sic!] considered a symbol." from http://crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s3.1) is talking
about the content of [object boxes] (or more generally: about the Pd
editor). Here this sentence is true, but you know that not every data entity in Pd can be used in object boxes as name or argument, while most things that looks like a number will become one here.

I agree that the implementation does not match the descriptions in the
manual. That's what is in important here. Yes, its possible to
generate any kind of symbols using certain techniques, but it is not
possible to generate any kind of symbol using any kind of symbol
generation. That's one example of where the inconsistency is a pain.
Try [symbol 43( for example, or this:

[43( | [symbol]

Is it really a good idea to have a separate type system in object
boxes versus the rest of Pd? What we need to come up with first is a
coherent idea of what Pd's type system should be, or make Pd
consistent with the idea it was built around. Otherwise we'll forever
have a confusing, hack job system where different objects and
externals have different ideas of how to intrepret symbols (which is
basically what we have now). Name another language you want to use
that doesn't have consistent typing?

...

...

...

But that's in conflict with having symbols that have things that can be intepreted as a number. So make Pd consistent, either it needs to be illegal to have symbols that can be interpreted as a number,

This could break some existing patches.

Do you have an examples? That would be very helpful. Off the top of my head, it seems that it would only break patches that rely on errors, which is not a very common situation.

What errors would patches rely on that use [makefilename %d] to
generate a symbol?

That's a clear case of where my proposed solution would help. Things
that expect symbols would interpret the message from [makefilename %d]
as a symbol, and things that expect floats would interpret the message
from [makefilename %d] as a float. So the kind of thing I'm talking
about would be like this:

[makefilename %d] | [float]

Then having the patch rely on the "error: float: no method for
'symbol'" error that is normally generated in that case. The part I
don't have a clear idea on is for things that expect both a symbol and
a float, how should [makefilename %d] be interpreted. My guess now is
that it should be interpreted as a symbol in that case.

.hc

Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra

Hi,

On Mon, Sep 05, 2011 at 02:34:30PM -0400, Hans-Christoph Steiner wrote:

On Sep 5, 2011, at 2:06 PM, Frank Barknecht wrote:

...

Here this sentence is true, but you know that not every data entity in Pd can be used in object boxes as name or argument, while most things that looks like a number will become one here.

I agree that the implementation does not match the descriptions in the manual.

We do not agree, because what I tried to say is that the implementation *does* match the description! :) In the Pd editor, i.e. in objects boxes, message boxes etc., certain things that look like a number will be converted to a number. ("+1" won't).

That's what is in important here. Yes, its possible to generate any kind of symbols using certain techniques, but it is not possible to generate any kind of symbol using any kind of symbol generation.

It is not possible to generate any kind of numercial symbol using the editor, and that's what the manual says. It's possible to generate "t_symbol"s using other techniques, if you need them, for example to get the string ".123" without it becoming "0.123". But this is nothing unusual, it's the same for pointers, gemlists, pdp-packets, probably GF grids etc.: You cannot "edit" these into a message box, but there are many objects that still will accept and create them.

Things that expect symbols would interpret the message from [makefilename %d] as a symbol, and things that expect floats would interpret the message from [makefilename %d] as a float. So the kind of thing I'm talking about would be like this:

[makefilename %d] | [float]

Then having the patch rely on the "error: float: no method for 'symbol'" error that is normally generated in that case.

Well, it prints an error because there *is* an error in the patch. The author should never have converted a float to a symbol and expect to still do float calculations with it.

Here are two similar errors:

[symbol three( | [+ four]

Ciao

Frank

On Mon, Sep 05, 2011 at 11:41:53PM -0700, Jonathan Wilkes wrote:

I think my proposal of having Pd automagically make floats out of selectors that look like numbers solves half of the problem, as well as being consistent with what's written in the last paragraph of 2.3.1.  The other half is already solved by [makefilename %d], and could be made more consistent by having message boxes automagically convert $1 in "symbol 15" to a symbol-atom.  Possibly the same for the arg to [symbol].

While I tend to agree and think this sounds sensible, it could clash with this part of the manual (first paragraph of 2.3.1) that hints at problems with numerical symbols as selectors:

"Messages contain a selector followed by any number of arguments. The selector is a symbol, which appears in the patch as a non-numeric string with no white space, semicolons, or commas."

I'm not sure what "appears in the patch" should mean. It definitly means that numercial-symbol selectors don't get shown and cannot be written into a patch, so you cannot use them in the editor where "real" selectors should be written, like in [route]: There's no [route "15"] in Pd, where "15" should mean a numerical symbol. And if you allow [s 15], should [table 15] also be allowed? And would 15 be a symbol or a float then?

It seems to be fine if [symbol 15( would act like [15(->[makefilename %d], but who really needs the former when you already have the latter? And what about symbols with whitespace, like [symbol My Documents/Drum Loop.wav]?

Additionally numbers inside messages or object boxes have so many special meanings in Pd (i.e. they turn "1 two three" into a list message, they change the mode of [select] or [route], they make [15] be [f 15] etc.), that it seems to me that some small changes here could open a Pandora's Box and the sole reason for this IMO is legalistic pedantry. Numbers maybe already are overloaded with automagic.

However I would like to see some proper quoting mechanism in the editor.

Ciao

Frank

----- Original Message -----

From: fbar fbar@footils.org To: "pd-list@iem.at" pd-list@iem.at Cc: Sent: Tuesday, September 6, 2011 3:53 AM Subject: Re: [PD] (breaking symbols) was Re: find a list of numbers in a text file

On Tue, Sep 06, 2011 at 09:44:33AM +0200, Frank Barknecht wrote:

...

I'm not sure what "appears in the patch" should mean. It

definitly means

...

that numercial-symbol selectors don't get shown and cannot be written into a patch, so you cannot use them in the editor where "real" selectors should be written, like in [route].

Forgot to add: Of course it is possible and legal to "use" numerical or non-printable symbols as selectors, but they have to be constructed dynamically and cannot be typed, in accordance with the restrictions mentioned in the manual. Instead something like this can be used:

[makefilename %d]   |   |                  [makefilename %d]   |                  |   [select symbol-dummy]

I used [makefilename %d] a lot in the rj library's [m_chorddict] dictionary for chords, where some chord names are proper symbols, like "m7", while others are floats like 7. The float-names get converted to symbols internally to look up chord notes in a data structure array keyed by symbols only (using [m_symbolarray]).

At what point are you using numerical-symbol selectors?  Everything you've described has the selector 'symbol'.

If you mean you let the user send symbols or floats as the key and convert internally, that's _exactly_ what I'm proposing.

Ciao

Frank

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

----- Original Message -----

From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: fbar fbar@footils.org; "pd-list@iem.at" pd-list@iem.at Sent: Tuesday, September 6, 2011 4:04 PM Subject: Re: [PD] (breaking symbols) was Re: find a list of numbers in a text file

On Sep 6, 2011, at 12:30 PM, Jonathan Wilkes wrote:

...

----- Original Message -----

...

From: fbar fbar@footils.org To: "pd-list@iem.at" pd-list@iem.at Cc: Sent: Tuesday, September 6, 2011 3:53 AM Subject: Re: [PD] (breaking symbols) was Re: find a list of numbers in

a text file

...

...

On Tue, Sep 06, 2011 at 09:44:33AM +0200, Frank Barknecht wrote:

...

I'm not sure what "appears in the patch" should mean.

It

...

...

definitly means

...

that numercial-symbol selectors don't get shown and cannot be

written

...

...

...

into a patch, so you cannot use them in the editor where

"real"

...

...

...

selectors should be written, like in [route].

Forgot to add: Of course it is possible and legal to "use"

numerical

...

...

or non-printable symbols as selectors, but they have to be constructed dynamically and cannot be typed, in accordance with the restrictions mentioned in the manual. Instead something like this can be used:

[makefilename %d]   |   |                  [makefilename %d]   |                  |   [select symbol-dummy]

I used [makefilename %d] a lot in the rj library's [m_chorddict] dictionary for chords, where some chord names are proper symbols, like "m7", while others are floats like 7. The float-names get

converted to

...

...

symbols internally to look up chord notes in a data structure array keyed by symbols only (using [m_symbolarray]).

At what point are you using numerical-symbol selectors?  Everything

you've

...

described has the selector 'symbol'.

If you mean you let the user send symbols or floats as the key and convert internally, that's _exactly_ what I'm proposing.

I guess I'm not clear on your proposal.  Is it that a "symbol" selector automatically converts things to a symbol?  That makes a lot of sense, and would help with other issues.  Then you could also make symbols with spaces, like:

[symbol 43( [symbol /home/hans/My Documents(

Well, that's something I've wanted for a long time.  But what I am proposing has to do with selectors, not symbol messages.

Problem: convert from symbol-atom to float-atom Proposal: if a selector happens to be in a form that can be interpreted by the naked eye as a valid Pd float, and the object receiving the message has a float method (and no anything method), then send a float to the object.

[r infinite-expressivity] | [1( <- float | [makefilename %d] <-- converted to symbol message (and the message arg is convert to a symbol-atom) | [list trim] <-- now we have a message with the selector 1 and no arguments | [route float] <-- seriously, it's a symbol-atom, not a float              | ------------+ | [float] <-- my proposal: give [float] a float-atom instead of a symbol-atom in this case | [route float] | [set $1, bang( | [s infinite-expressivity]

But if there were a really nice quoting mechanism, that would probably be much clearer.

etc.

A quoting mechanism would also help.  We could probably get away with only .  For example, \ for spaces, like:

[symbol /home/hans/My\ Documents( [symbol I\ like\ lots\ of\ \ \ \ \ spaces( [symbol commas,\ in\ symbols( [symbol semi-colon;\ in\ symbols(

That looks really ugly to me.  What's wrong with "quotes"?

And last but least, and its already in there:

[symbol \43( [symbol -21343( [symbol -0.2e59(

Anything that just \ couldn't cover?

[openpanel] <- outputs /home/hans/My documents | [set symbol $1( | [ ( <-- What's printed here? ...My documents or ...My\ documents?

.hc

---

If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.            - Thomas Jefferson

On Sep 8, 2011, at 12:59 PM, Hans-Christoph Steiner wrote:

On Sep 7, 2011, at 5:46 PM, Jonathan Wilkes wrote:

...

----- Original Message -----

...

From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: fbar fbar@footils.org; "pd-list@iem.at" pd-list@iem.at Sent: Tuesday, September 6, 2011 4:04 PM Subject: Re: [PD] (breaking symbols) was Re: find a list of numbers in a text file

On Sep 6, 2011, at 12:30 PM, Jonathan Wilkes wrote:

...

----- Original Message -----

...

From: fbar fbar@footils.org To: "pd-list@iem.at" pd-list@iem.at Cc: Sent: Tuesday, September 6, 2011 3:53 AM Subject: Re: [PD] (breaking symbols) was Re: find a list of numbers in

a text file

...

...

On Tue, Sep 06, 2011 at 09:44:33AM +0200, Frank Barknecht wrote:

...

I'm not sure what "appears in the patch" should mean.

It

...

...

definitly means

...

that numercial-symbol selectors don't get shown and cannot be

written

...

...

...

into a patch, so you cannot use them in the editor where

"real"

...

...

...

selectors should be written, like in [route].

Forgot to add: Of course it is possible and legal to "use"

numerical

...

...

or non-printable symbols as selectors, but they have to be constructed dynamically and cannot be typed, in accordance with the restrictions mentioned in the manual. Instead something like this can be used:

[makefilename %d] | | [makefilename %d] | | [select symbol-dummy]

I used [makefilename %d] a lot in the rj library's [m_chorddict] dictionary for chords, where some chord names are proper symbols, like "m7", while others are floats like 7. The float-names get

converted to

...

...

symbols internally to look up chord notes in a data structure array keyed by symbols only (using [m_symbolarray]).

At what point are you using numerical-symbol selectors? Everything

you've

...

described has the selector 'symbol'.

If you mean you let the user send symbols or floats as the key and convert internally, that's _exactly_ what I'm proposing.

I guess I'm not clear on your proposal. Is it that a "symbol" selector automatically converts things to a symbol? That makes a lot of sense, and would help with other issues. Then you could also make symbols with spaces, like:

[symbol 43( [symbol /home/hans/My Documents(

Well, that's something I've wanted for a long time. But what I am proposing has to do with selectors, not symbol messages.

Problem: convert from symbol-atom to float-atom Proposal: if a selector happens to be in a form that can be interpreted by the naked eye as a valid Pd float, and the object receiving the message has a float method (and no anything method), then send a float to the object.

[r infinite-expressivity] | [1( <- float | [makefilename %d] <-- converted to symbol message (and the message arg is convert to a symbol-atom) | [list trim] <-- now we have a message with the selector 1 and no arguments | [route float] <-- seriously, it's a symbol-atom, not a float | ------------+ | [float] <-- my proposal: give [float] a float-atom instead of a symbol-atom in this case | [route float] | [set $1, bang( | [s infinite-expressivity]

But if there were a really nice quoting mechanism, that would probably be much clearer.

Yes, I agree that [float] and [symbol] should also do conversions. A good example would be Python's str() and float().

...

...

etc.

A quoting mechanism would also help. We could probably get away with only . For example, \ for spaces, like:

[symbol /home/hans/My\ Documents( [symbol I\ like\ lots\ of\ \ \ \ \ spaces( [symbol commas,\ in\ symbols( [symbol semi-colon;\ in\ symbols(

That looks really ugly to me. What's wrong with "quotes"?

The nice part would be that it would only add one special character, , which is currently not allowed anyway. Adding "" or '' or `` quotes means some kind of backwards incompatibility, since '"` are currently all valid characters to have in a symbol. Another easy option would be to use

I think this would be made much easier if the symbol selector forced the message to be a symbol, then you could do:

[symbol /home/hans/My Documents( [symbol I like lots of\ \ \ \ \ spaces( [symbol commas, in symbols( [symbol semi-colon; in symbols( [symbol \43( [symbol -21343( [symbol -0.2e59(

Then you'd only need the \ when its in other places, like:

[route \43]

...

...

And last but least, and its already in there:

[symbol \43( [symbol -21343( [symbol -0.2e59(

Anything that just \ couldn't cover?

[openpanel] <- outputs /home/hans/My documents | [set symbol $1( | [ ( <-- What's printed here? ...My documents or ...My\ documents?

Depends on what the symbol selector does. If the symbol selector forces the rest of the message to be a symbol, then there wouldn't need to be any backslashes there. But it would probably be a good idea to have them there anyway.

Here's an example of this idea applied to the [symbol] and [float] boxes.

https://github.com/pd-projects/newtype

Also, I attached a Linux 32-bit version and a Mac OS X universal.

.hc

News is what people want to keep hidden and everything else is publicity. - Bill Moyers

On Thu, 8 Sep 2011, Hans-Christoph Steiner wrote:

Yes, I agree that [float] and [symbol] should also do conversions. A good example would be Python's str() and float().

I believe that the implicit conversions should be at a lower level than that, because then, they can apply all over pd, wherever Type Mismatch errors would happen.

...

[set symbol $1( | [ ( <-- What's printed here? ...My documents or ...My\ documents?

Depends on what the symbol selector does. If the symbol selector forces the rest of the message to be a symbol, then there wouldn't need to be any backslashes there. But it would probably be a good idea to have them there anyway.

The problem with relying on the symbol selector for that, is that it is limited to cases where you only want to pass a single symbol, which does not apply to lists and other.

[set open 1(

I'm trying to store a command for opening a file whose name is just «1». This can't use the symbol selector.

[set list 666 383.3801 986.3246(

this list contains two phone numbers I'd like to keep as symbols, but also has a user id that I want to keep as float, and we have three elements in the same messages, and only one selector at once.

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

On Tue, 6 Sep 2011, Hans-Christoph Steiner wrote:

Anything that just \ couldn't cover?

The current backslash scheme in the parser does not handle things like \n, \t, \x with two hex digits, \u with four hex digits, \0 for nul character, etc. That's because the current backslash only means that the next character is to be taken as-is.

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

On Tue, 6 Sep 2011, fbar wrote:

Forgot to add: Of course it is possible and legal to "use" numerical or non-printable symbols as selectors, but they have to be constructed dynamically and cannot be typed, in accordance with the restrictions mentioned in the manual.

If you put a single leading backslash in front of the number in the .pd file, you will get A_SYMBOL in pd, but Pd will save it back to A_FLOAT because it will forget to add the backslash... likewise if you edit the box containing that symbol.

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

On Sep 6, 2011, at 2:55 PM, Mathieu Bouchard wrote:

On Tue, 6 Sep 2011, fbar wrote:

...

Forgot to add: Of course it is possible and legal to "use"
numerical or non-printable symbols as selectors, but they have to be constructed dynamically and cannot be typed, in accordance with the restrictions mentioned in the manual.

If you put a single leading backslash in front of the number in
the .pd file, you will get A_SYMBOL in pd, but Pd will save it back
to A_FLOAT because it will forget to add the backslash... likewise
if you edit the box containing that symbol.

Wow, that's fascinating. So Pd already has a way to store and load
symbols like "43". Miller, any comment on that? Or is it just a side
effect of something else.

Here's a little example of this in action (this time with patch
attached):

.hc

Access to computers should be unlimited and total. - the hacker ethic

----- Original Message -----

From: Frank Barknecht fbar@footils.org To: "pd-list@iem.at" pd-list@iem.at Cc: Sent: Tuesday, September 6, 2011 3:44 AM Subject: Re: [PD] (breaking symbols) was Re: find a list of numbers in a text file

On Mon, Sep 05, 2011 at 11:41:53PM -0700, Jonathan Wilkes wrote:

...

I think my proposal of having Pd automagically make floats out of selectors that look like numbers solves half of the problem, as well as being consistent with what's written in the last paragraph of 2.3.1.

The

...

other half is already solved by [makefilename %d], and could be made more consistent by having message boxes automagically convert $1 in "symbol 15" to a symbol-atom.  Possibly the same for the arg to [symbol].

While I tend to agree and think this sounds sensible, it could clash with this part of the manual (first paragraph of 2.3.1) that hints at problems with numerical symbols as selectors:

"Messages contain a selector followed by any number of arguments. The selector is a symbol, which appears in the patch as a non-numeric string with no white space, semicolons, or commas."

That already clashes with the Vanilla implementation:

[5( | [makefilename %d] | [set, addsemi, add2 $1 127, bang( | [ (

[vsl] <-- receive-name is '5'

I'm not sure what "appears in the patch" should mean.

Then keep reading the manual: "When a message is passed to something (which is often an inlet of a box but could be anything that can receive a message)..."

It clearly means (at least) anything that "appears in the patch," which is at odds with the example I gave above.  Anyway, the title of the section is "Anatomy of a message", not "Anatomy of how things you type in an object box get interpreted."

It definitly means that numercial-symbol selectors don't get shown and cannot be written into a patch, so you cannot use them in the editor where "real" selectors should be written, like in [route]: There's no [route "15"] in Pd, where "15" should mean a numerical symbol. And if you allow [s 15], should [table 15] also be allowed? And would 15 be a symbol or a float then?

The '15' in [s] and [table] isn't a selector, it's a float argument, and the help files would be adjusted accordingly to say that you can give either a symbol or float argument to give a name to the symbolic-receiver.

It seems to be fine if [symbol 15( would act like [15(->[makefilename %d], but who really needs the former when you already have the latter? And what about symbols with whitespace, like [symbol My Documents/Drum Loop.wav]?

Additionally numbers inside messages or object boxes have so many special meanings in Pd (i.e. they turn "1 two three" into a list message, they change the mode of [select] or [route],

[select] doesn't need modes, and [route] is poorly designed and should really be two separate objects.

they make [15] be [f 15] etc.),

None of your three examples would change under my proposal.

that it seems to me that some small changes here could open a Pandora's Box and the sole reason for this IMO is legalistic pedantry.

Ha!  It's obviously not the "sole reason" we're discussing this.  Look at the title of the thread-- would you have been comfortable writing that as the first response to the OP?

Numbers maybe already are overloaded with automagic.

However I would like to see some proper quoting mechanism in the editor.

That could be a way to go. How do you do it in a way that doesn't open a Pandora's box and that doesn't break patches going forward?

-Jonathan

Ciao

Frank

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

----- Original Message -----

From: Mathieu Bouchard matju@artengine.ca To: Frank Barknecht fbar@footils.org Cc: "pd-list@iem.at" pd-list@iem.at Sent: Friday, September 9, 2011 6:29 PM Subject: Re: [PD] (breaking symbols) was Re: find a list of numbers in a text file

On Tue, 6 Sep 2011, Frank Barknecht wrote:

...

I'm not sure what "appears in the patch" should mean. It

definitly means that numercial-symbol selectors don't get shown and cannot be written into a patch, so you cannot use them in the editor where "real" selectors should be written, like in [route]: There's no [route "15"] in Pd, where "15" should mean a numerical symbol.

I proposed such a syntax in the past... 2006-2007, I think.

It would take care of :

"15" = \15 but looks less weird

"" = really an empty string (just like the &s_ given by A_DEFSYMBOL, that you nearly can't produce otherwise)

[symbol(

"hello      world" = hello\ \ \ \ \ \ world but less annoying to type.

"hello  " = hello\ \ \  but at least it wouldn't be confusing like ending a symbol by backslash space and then immediately using a space separator.

";" = ;

"," = ,

but it means :

" would be syntax error

" would mean double-quote char

""" too

Those conventions are very similar to Tcl and Bash.

However, I don't know what "$1" would do, nor why it's a good idea, or a bad idea.

Also, how do you go about converting all the places in the current documentation where comments have quotes in them?

-Jonathan

Also, how do we quote ";" when writing to a file ? a literal semicolon in a messagebox would be written as ;, which has to be written \; in the file, but if a user were to write ";", what will the messagebox write to the .pd file ?

---

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

----- Original Message -----

From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Frank Barknecht fbar@footils.org; "pd-list@iem.at" pd-list@iem.at Sent: Saturday, September 10, 2011 3:40 PM Subject: Re: [PD] (breaking symbols) was Re: find a list of numbers in a text file

On Fri, 9 Sep 2011, Jonathan Wilkes wrote:

...

...

"" = really an empty string (just like the &s_ given by

A_DEFSYMBOL, that you nearly can't produce otherwise)

...

[symbol(

And also if you do $1 inside of a DOLLSYM, you will get a default empty string, though not separately, because it joins it to another symbol.

However, if you write $1$2 as a DOLLSYM and the abstraction has no arguments, you will produce the empty symbol without using any objects to do so (other the abstraction that you just made, and the object you are passing this argument to).

...

Also, how do you go about converting all the places in the current

documentation where comments have quotes in them?

I don't know. Very good point. Writing the symbol foo as "foo" with the doublequotes is allowed, but would be canonically converted to just foo again, because atom_string would figure that it does not benefit from having the double-quotes...

We need a comment type in which the whole comment is a single symbol,

Is there a limit on the size of a symbol?

all of the time. Its code needs to be more separated from parsed-text boxes such as objectboxes and messageboxes, while currently, nearly all of the code is shared.

---

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

On Sep 10, 2011, at 9:25 PM, Jonathan Wilkes wrote:

----- Original Message -----

...

From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Frank Barknecht fbar@footils.org; "pd-list@iem.at" <pd-list@iem.at

...

Sent: Saturday, September 10, 2011 3:40 PM Subject: Re: [PD] (breaking symbols) was Re: find a list of numbers
in a text file

On Fri, 9 Sep 2011, Jonathan Wilkes wrote:

...

...

"" = really an empty string (just like the &s_ given by

A_DEFSYMBOL, that you nearly can't produce otherwise)

...

[symbol(

And also if you do $1 inside of a DOLLSYM, you will get a default
empty string, though not separately, because it joins it to another symbol.

However, if you write $1$2 as a DOLLSYM and the abstraction has no
arguments, you will produce the empty symbol without using any objects to do
so (other the abstraction that you just made, and the object you are passing this
argument to).

...

Also, how do you go about converting all the places in the current

documentation where comments have quotes in them?

I don't know. Very good point. Writing the symbol foo as "foo" with the doublequotes is allowed, but would be canonically
converted to just foo again, because atom_string would figure that it does not benefit
from having the double-quotes...

We need a comment type in which the whole comment is a single symbol,

Is there a limit on the size of a symbol?

Yes, I believe its MAXPDSTRING defined in m_pd.h or some other header.

.hc

"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White

On Sat, 10 Sep 2011, Hans-Christoph Steiner wrote:

I agree the "" style would match other languages and things quite well and might be clearer, but breaks backwards compatibility, though not horribly. We could start with the \ method, and if that is too painful, add a "" method. They would be complimentary. Certainly most syntaxes that have "" also have \ escaping. Internet search input is one notable exception.

For this, I had thought about using some kind of flag (checkbox) to decide the parser you want to use for a given patch. I didn't enjoy the idea, but saw it as necessary for the transition. (?)

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

On Sep 6, 2011, at 1:16 PM, martin.peach@sympatico.ca <martin.peach@sympatico.ca

wrote:

...

Date: Tue, 6 Sep 2011 08:12:15 +0200 From: fbar@footils.org To: hans@at.or.at CC: pd-list@iem.at Subject: Re: [PD] (breaking symbols) was Re: find a list of

numbers in a text file

...

Hi,

On Mon, Sep 05, 2011 at 02:34:30PM -0400, Hans-Christoph Steiner

wrote:

...

...

Then having the patch rely on the "error: float: no method for 'symbol'" error that is normally generated in that case.

Well, it prints an error because there *is* an error in the patch.

The

...

author should never have converted a float to a symbol and expect to still do float calculations with it.

Yes, I think it ought to be up to the external to implement its own
symbol-to-float converter since there is no universally valid way of
doing it. The same pattern will have different meanings in different context
and Pd can't be expected to know what is expected in a specific case.

Martin

That sounds like a recipe for disaster, then we end up with multiple,
incompatible ways of doing this. I don't think anyone is proposing
that symbols like "four" get converted to 4, but only symbols like 43,
5.22, -234, etc. Things that can be directly converted from a char*
to a float with a standard function.

.hc

"Making boring techno music is really easy with modern tools, but with
live coding, boring techno is much harder." - Chris McCormick

On Sep 6, 2011, at 4:21 PM, martin.peach@sympatico.ca <martin.peach@sympatico.ca

wrote:

From: hans@at.or.at To: martin.peach@sympatico.ca Date: Tue, 6 Sep 2011 15:57:32 -0400 CC: pd-list@iem.at Subject: Re: [PD] (breaking symbols) was Re: find a list of numbers
in a text file

On Sep 6, 2011, at 1:16 PM, martin.peach@sympatico.ca <martin.peach@sympatico.ca

...

wrote:

...

Date: Tue, 6 Sep 2011 08:12:15 +0200 From: fbar@footils.org To: hans@at.or.at CC: pd-list@iem.at Subject: Re: [PD] (breaking symbols) was Re: find a list of

numbers in a text file

...

Hi,

On Mon, Sep 05, 2011 at 02:34:30PM -0400, Hans-Christoph Steiner

wrote:

...

...

Then having the patch rely on the "error: float: no method for 'symbol'" error that is normally generated in that case.

Well, it prints an error because there *is* an error in the patch.

The

...

author should never have converted a float to a symbol and expect to still do float calculations with it.

Yes, I think it ought to be up to the external to implement its own
symbol-to-float converter since there is no universally valid way of
doing it. The same pattern will have different meanings in different context
and Pd can't be expected to know what is expected in a specific case.

Martin

That sounds like a recipe for disaster, then we end up with
multiple, incompatible ways of doing this. I don't think anyone is
proposing that symbols like "four" get converted to 4, but only
symbols like 43, 5.22, -234, etc. Things that can be directly
converted from a char* to a float with a standard function.

I think someone might well want to make an external that can take
'four' as 4. Or a symbol '4+2' that would become a float 6.0. And obviously Pd should not be doing that all the time because most
of the time that is not the right thing to do. The disaster would be if Pd tried to guess what the user intends
based on some general idea of what Pd is 'for'. For instance I've been working on an xbee external where I need to
specify numbers like 0x0a060123 for the remote address. I do that by interpreting the symbol as a 64-bit integer internally
but I would not expect any other external to do this unless it needs
to. Otherwise the user would have to manually convert the number (which
is conventionally given in hexadecimal form) into a bunch of decimal
numbers small enough to be represented as float and then the
external would combine them internally.

Martin

Yeah, I agree, I have no problem if someone wants to make an externals
that interprets 4+2 or "four" as 4, but it doesn't seem like something
that should be in the core.

About hex 0x form, that could conceivably fall under the "anything
that looks like a number is a float", as least for programmers. In
most programming languages, 0x10 is just a number like 16.

.hc

If you are not part of the solution, you are part of the problem.

On Fri, 2011-09-09 at 15:05 +0200, Frank Barknecht wrote:

Hi,

On Wed, Sep 07, 2011 at 02:13:01PM -0400, Hans-Christoph Steiner wrote:

...

About hex 0x form, that could conceivably fall under the "anything that looks like a number is a float", as least for programmers.

I really disagree with your assumption, that in Pd, "anything that looks like a number is a float". This is simlpy not how Pd works or is programmed, it's not in the manual [1] and [makefilename %d] proves the opposite is true: Some symbols can indeed look a lot like numbers. I think, your wrong premise leads to wrong conclusions and should be reconsidered.

[1] Here are some occurrences of you premise:

• "Anything that is not a valid number os considered a symbol."

appears in "2.1.2. object boxes" and talks about object boxes.

"2.3.1. anatomy of a message" "The selector is a symbol, which appears in the patch as a non-numeric string with no white space, semicolons, or commas". Note the "appears in a patch", which again hints at the well-known "feature" of the editor to convert things that look like numbers to floats.

Same chapter: "It is possible to type messages which start with a number, which cannot be used as a selector." Note the "type".

How would you then describe how Pd judges the difference between a symbol and a float? I wish there was more on this topic in the manual, but there is not. As for your quoted sentence, context is key here, its talking about the implied float and list selectors:

"It is possible to type messages which start with a number, which cannot be used as a selector. A single number is always given the "float" selector automatically, and a message with a number followed by other arguments is given the selector "list"."

And indeed, if I was only going on what the manual said, it would be a very weak argument. Mostly, I'm going on how the type system works. You can directly interface the automatic typing of atoms by adding arguments in an object or message box. It is not currently possible to generate a "456" symbol by typing something into a message or object box. And [makefilename %d] was added many years after the initial type system was implemented (especially if you consider Max) http://lists.puredata.info/pipermail/pd-list/1999-10/000765.html so it is also not representative of the type system.

More importantly: how should it act to be useful. Obviously [makefilename %d] is useful. That's why I just posted those [symbol2] and [float2] objects on this thread. I think these two objects show that we can add conversion between symbols and floats without negatively impacting anything else. Please test them and let me know what you think. I think these can replace the built-in [symbol] and [float].

.hc

On Fri, 9 Sep 2011, Hans-Christoph Steiner wrote:

How would you then describe how Pd judges the difference between a symbol and a float? I wish there was more on this topic in the manual, but there is not.

It's quite hard to do biblical interpretation... and it doesn't necessarily pay off.

In the facts, programmes are written for machines to execute, and only incidentally for people to read. So, issues of backward compatibility happen regardless of what the manual actually says, and it's possible that a programme doesn't reflect the intent, that a manual doesn't reflect the intent, and/or that a manual doesn't reflect the programme. How you resolve such a conflict is... some kind of triple-edged sword... but remember that the intent in question needs not to be the original intent, I'm talking about the current intents.

E.g. if you pass a symbol through [trigger float], which is documented as something that «converts» data, and what it does to any symbol is turn it to 0, you can safely throw away both the documentation and the presumed original intent and move on. Then you may decide a new intent that is useful instead of nonsensical.

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

On Sun, 11 Sep 2011, Jonathan Wilkes wrote:

[trigger anything] | [b] can be shortened to: [trigger bang]

can be shortened to :

[b]

And finally: -1) [t a] as a cheap hack due to lack of segmented patching cords

even with segmented cords, [t a] is useful as a hub. That's what I use it for 95 % of the time, and segmented cords will not change that.

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

On Mon, 12 Sep 2011, Jonathan Wilkes wrote:

Yes, I forgot about the hub.  There's that, too.  But if you have a [t a] with one wire in and one wire out then chances are you ought to have used a segmented wire.  But those aren't available, so you use [t a], and in these cases I give it a minus one.

Not necessarily... when I have a [t a] with a single wire on each side, chances are that it's a past hub or a future hub or both.

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

On Tue, 13 Sep 2011, Andy Farnell wrote:

Exactly. I'll often use one (or its signal equivalent [*~ 1])

[+~ 0] takes less CPU.

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

On Wed, 7 Sep 2011, Hans-Christoph Steiner wrote:

Yeah, I agree, I have no problem if someone wants to make an externals that interprets 4+2 or "four" as 4, but it doesn't seem like something that should be in the core.

Well, there would be no conflict if such a feature existed, because it would only happen when atom_getfloat() is called on a A_SYMBOL atom, and it would only happen when that symbol does not parse as a float (strtof would return 4 and report to have stopped parsing at the + sign, meaning that the whole symbol is not just 4).

However, nearly all programming languages that have implicit conversions would just let arithmetic stay out of the core.

Pd's [expr] and Tcl's [expr] are two notable weird exceptions, in which you can pass a symbol instead of a float, where the intention of the user was to allow using a float in the expression, yet you can pass 4+2 or whatever :

banging [expr $1] with $1=4+2 gives 6

banging [expr $1*-1] with $1=4+2 gives 4+2*-1 = 4-2 = 2 (really)

banging [expr ($1)*-1] with $1=4+2 gives 4

making it so that the argument is float is longer : you need to use $f1 with an additional [f $1] (and in cases with multiple inlets, you may have to [loadbang] too, etc)

I suggest to stick with the simple stuff, that is, if you get "4+2" as a A_SYMBOL and atom_getfloat is used, you'd get « error: 4+2 can't be cast to float », because strtof() stopped before the end of the string. That's why you have to avoid atof... otherwise you'd cast 4+2 to 4 and give no error, and that's weird.

perl -e 'print("4+2"+0,"\n")' gives 4. (I don't approve.)

tcl's «expr "4+2" + 0» gives 6.

tcl's «expr {"4+2" + 0}» gives : can't use non-numeric string as operand of "+"

About hex 0x form, that could conceivably fall under the "anything that looks like a number is a float", as least for programmers.  In most programming languages, 0x10 is just a number like 16.

Yeah, but it's a new incompatibility, just like changing the meaning of doublequotes. I don't mean that we shouldn't do it, just that it is something to be careful about.

Martin is not alone to use the 0x syntax for making symbols that represent ints bigger than what float32 can hold (which is limited to int25). I also use that for window-id of X11 screenshots, as used in http://gridflow.ca/help and also the Patch-dans-Patch series.

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

On Sep 10, 2011, at 3:01 PM, Mathieu Bouchard wrote:

On Tue, 6 Sep 2011, martin.peach@sympatico.ca wrote:

...

The disaster would be if Pd tried to guess what the user intends
based on some general idea of what Pd is 'for'. For instance I've
been working on an xbee external where I need to specify numbers
like 0x0a060123 for the remote address. I do that by interpreting
the symbol as a 64-bit integer internally but I would not expect
any other external to do this unless it needs to.

The xbee external uses a function that shows that it expects to read
a symbol where you gave it the 0x0a060123 symbol. Therefore Pd would
not do any implicit conversion, because it's being requested to give
a symbol atom as a symbol.

However, if ever 0x0a060123 is to be parsed as a float (that's a
different issue, actually), then xbee would be getting 168165667
rounded to 168165664 and then it would be implicitly converted to
gensym("168165664"). But that's a parser difference, and not a
difference of implicit type conversions. The solution would be to
backslash it or doublequote it.

Perhaps it is confusing because we are talking about several related
propositions at once :

• implicit conversion to replace type mismatch errors

• getting atom_string to write backslashes to files and to

messageboxes, to match what the parser can already do

• modifying both the parser and atom_string, to change the meaning of doublequotes

and AFAIK, no-one talked about adding support for aztec numerals or
parsing «half-dozen» as meaning {A_FLOAT,6}.

I'm thinking now to first try a more python style approach, and have
something like str() and float() rather than automatic conversions. I
implemented this in two objects that are meant to replace [symbol] and
[float], [symbol2] and [float2]. Here's the library:

https://github.com/pd-projects/newtype

There is definitely a universally valid way of converting a symbol to
a float because Pd converts strings to floats both when receiving
floats from the GUI and when reading floats from the .pd file. I
implemented this in a test file and I think it matches Pd's
implementation in every case that I could think of:

https://github.com/pd-projects/newtype/blob/master/test_symbol2float.c

Converting from a float to a symbol in the code is simple, that's just
sprintf(buf, "%g"), its in the code a lot, like in atom_string() and
atom_getsym().

As for all the \ cases, I don't really know how to handle \n, \t, etc.
yet. As for unicode chars, I think we should just support unicode
completely then people put the actual character rather than the \0x234
form. We have full unicode support for a lot of left-to-right
alphabets. Things like Chinese, arabic, etc. have issues with box
sizing, but the characters show up correctly.

.hc

Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra

On 2011-09-10 01:57, Mathieu Bouchard wrote:

On Tue, 6 Sep 2011, martin.peach@sympatico.ca wrote:

...

Yes, I think it ought to be up to the external to implement its own symbol-to-float converter since there is no universally valid way of doing it. The same pattern will have different meanings in different context and Pd can't be expected to know what is expected in a specific case.

Give examples...

Which other ways are you thinking about, apart from something that behaves more or less like strtof ?

OK, for example an object that converts names of numbers to floats:

[one two three( | [nametof] | 1.0 2.0 3.0

or binary to float:

[b101010{ | [btof] | 42.0

or imaginary numbers:

[5+3i( | [itof] | | 5.0 3.0

or even some kind of [expr] that takes symbolic input:

[atan{.007)( | [sexpr] | 0.40106

None of the above would work properly with a default symbol-to-float method. Each needs to parse its input according to its own specific meaning-space.

Martin

On 2011-09-10 13:46, Mathieu Bouchard wrote:

On Sat, 10 Sep 2011, Martin Peach wrote:

...

...

Which other ways are you thinking about, apart from something that behaves more or less like strtof ?

OK, for example an object that converts names of numbers to floats: or binary to float: or imaginary numbers: or even some kind of [expr] that takes symbolic input: None of the above would work properly with a default symbol-to-float method. Each needs to parse its input according to its own specific meaning-space.

So what's the problem with having an implicit cast that does the strtof that people want in 99,99 % of the cases, and still be able to use explicit means to convert things like MCMLXXVIII to float in whichever way you like ?

Nothing.

It's not about all-encompassing conversions, it's about defaults.

If you say so. I was just saying that the default should avoid the all-encompassing conversion and not try second-guessing the users' intentions. It's probably safe to have Pd convert a symbol to a float by default iff there is no symbol method and there is a float method. Trying to interpret every possible string as a float would add huge amount of bloat and delay to core Pd.

Martin

On Tue, 6 Sep 2011, Frank Barknecht wrote:

It is not possible to generate any kind of numercial symbol using the editor, and that's what the manual says. It's possible to generate "t_symbol"s using other techniques, if you need them, for example to get But this is nothing unusual, it's the same for pointers, gemlists, pdp-packets, probably GF grids etc.

Well, almost.

GF reparses its objectbox arguments for parens and commas. With commas it makes init-messages. With parens it makes A_BINBUF atoms, which are nested lists (can you say « list atom » ?)

That's happening by default for all the classes, except that a class can turn off this behaviour.

Then there is another step.

a GF constructor that receives an A_BINBUF where a Grid* is declared, converts that binbuf to a grid, so that « 2 3 4 s # 5 6 7 » means « make a grid of shorts (s) of 2 by 3 by 4, and for all elements (in usual order), fill with 5,6,7,5,6,7,5,6,7,... ». (there are also simpler syntaxes for simpler cases)

GF used to also parse parens in messageboxes, but that is now gone. However, all grid-accepting inlets also accept list-messages and convert them to grids using the same syntax (except the parens).

Of course, GF does not modify the code of pd's messagebox class. (so far...)

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

----- Original Message -----

From: Mathieu Bouchard matju@artengine.ca To: Hans-Christoph Steiner hans@at.or.at Cc: Jonathan Wilkes jancsika@yahoo.com; "pd-list@iem.at" pd-list@iem.at; Chris McCormick chris@mccormick.cx; Miller Puckette msp@ucsd.edu Sent: Monday, September 5, 2011 1:11 PM Subject: Re: [PD] (breaking symbols) was Re: find a list of numbers in a text file

On Sun, 4 Sep 2011, Hans-Christoph Steiner wrote:

...

I think you are missing the point of what I am saying.  I am not saying

with we implement a strict duck typing mimicing Ruby or Python.

I think you are missing the point of what I am saying. I am saying that you are using the wrong words for that.

...

So in the sense of Pd, anything that can be intepreted as a number should

be. But that's in conflict with having symbols that have things that can be intepreted as a number.  So make Pd consistent, either it needs to be illegal to have symbols that can be interpreted as a number,

This could break some existing patches.

...

or maybe symbols that can be interpreted as a number behave like a float

when something is expecting a float.

That's what Tcl and Perl do for ints, floats and strings.

And that's what I want for Pd.

However, I wonder if this would cause more instances of people running out of memory from filling up the symbol table.  Currently if you generate an error from sending a symbol atom where a float is expected, you know something screwy is going on, post to the list, and figure out the problem and generate float-atoms instead.  However, if that's not an error, you increase the chance of someone needlessly generating lots of unique symbol-atoms (maybe with an accumulator, or importing them from a database as symbol-atoms instead of floats), and having problems or crashes that are less obvious.

-Jonathan

They don't call it duck-typing though, and no-one does.

duck-taping?  No.

How about goose-for-duck-swapping?  As in you send a duck (A_SYMBOL), and if the object expects a number then Pd swaps the duck for a goose (A_FLOAT).

---

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

On Sun, 4 Sep 2011, Jonathan Wilkes wrote:

That's right, I wrote the wrong one.  I have a bad habit of getting opposites mixed up-- if I'm not careful I'll create a [max] to output the greater of two numbers.

[max] does output the greater of two numbers.

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

On Sun, 4 Sep 2011, Jonathan Wilkes wrote:

...

From: Mathieu Bouchard matju@artengine.ca [max] does output the greater of two numbers.

Ha!  Then my _misunderstanding_ is that [max 5] = "make 5 the maximum value that can come out of the outlet".  I have to open the help file every time I use [min] [max] to see which is the real behavior, and which the figment of my imagination.

It's the same max and min as in math textbooks and as in a bunch of programming languages and libraries.

http://www.cplusplus.com/reference/algorithm/max/ http://reference.wolfram.com/mathematica/ref/Max.html http://developer.gnome.org/glib/2.29/glib-Standard-Macros.html#MAX:CAPS http://www.tutorialspoint.com/python/number_min.htm http://www.ruby-doc.org/core/classes/Enumerable.html#M001504 http://php.net/manual/en/function.max.php etc

I don't recall ever seeing any language or library swap the meaning of min and max. It seems to be very standard.

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

On Sun, 4 Sep 2011, Jonathan Wilkes wrote:

...

From: Mathieu Bouchard matju@artengine.ca I don't recall ever seeing any language or library swap the meaning of min and max. It seems to be very standard.

Why would any of them swap it?

Well, I figured that given that it's a very common confusion for people learning pd, it would not be surprising if there were programming languages (or libraries) that named them the other way around... yet I haven't ever found any.

Pd's syntax stands out against all those examples because it is the only one that explicitly shows only a single argument after the function name.  So while I could write the Pd syntax as "max y", it really means something more like max(x, y) where x is visually represented by a small black rectangle to the top left of the word "max".

There are other examples where there aren't two args after the function name (apart those that allow variable number of args). But I haven't listed any.

Smalltalk has infix min and max written like : x := 10 max: 20.

where "max:" is the selector, and 10 is the receiver.

Forth (and related) takes its arguments before the name of the function.

Currying means that you can pass to a function only part of the args, and in that case you get another function that takes the rest of the args, and you can pass that function around or store it. It's available in several language families. this can mean that you can do stuff like :

foo = max(10) print foo(20)

as an alternate form of

print max(10,20)

which means you can also do it like

print max(10)(20)

but the useful uses of this feature involve storing foo or passing it around.

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

On Sun, 2011-09-04 at 14:23 -0400, Hans-Christoph Steiner wrote:

On Aug 31, 2011, at 2:33 AM, Chris McCormick wrote:

...

On Tue, Aug 30, 2011 at 11:19:46PM -0700, Miller Puckette wrote:

...

...

I am in favour of having that functionality as part of [list] and
those names look good to me. For the functionality you describe
maybe something like [list ascii2symbol] and [list symbol2ascii]?
Those would also be pretty useful!

I am currently making a [split] abstraction based on Jamie's work.
I will send it through when I am done - or you can just look at
symbol2list's source which IOhannes has re-licensed in a message
to this list for use in Pd:

hmm... another possibility, as in lisp: "list explode" and "list
implode" ?

Also good!

...

My idea is that, once this is in Pd vanilla, the "2/3" -> "2" "3"
type of split is easy enough to program in an abstraction, but it's
presently not possible at all; meanwhile, the funtionality I'm describing is
pretty canonical and hard to split up into finer components in any way I
can see.

Ah, ok, so you could do:

bat/cat/rat -> 98 97 116 47 99 97 116 47 114 97 116

and then you would run through the number list finding 47 ("/") and
re-building the separate symbols using the reverse operation.

I guess this would be cool because it would also allow you to store
proper strings with all kinds of characters in regular Pd arrays,
which might be fun. Hmmm, also many other things!

...

easy enough to program in an abstraction, but it's presently not possible at all;

After looking at Jonathan's ratio splitting abstraction I think this
might actually be possible with [makefilename] madness, but it's
much uglier than what you propose: http://lists.puredata.info/pipermail/pd-list/2011-08/090196.html

Definitely check out Bryan Jurish's moocow with its bytes2any and
any2bytes. They work quite nicely for converting between messages and
lists of byte floats and are easy to use.

I made a vanilla abstraction similar to [byte2any] based on the aforementioned [makefilename] madness. Just for the sake of this discussion. Check the attachment.

Roman

On Sep 4, 2011, at 9:39 PM, Chris McCormick wrote:

On Sun, Sep 04, 2011 at 02:23:59PM -0400, Hans-Christoph Steiner
wrote:

...

...

After looking at Jonathan's ratio splitting abstraction I think this might actually be possible with [makefilename] madness, but it's
much uglier than what you propose: http://lists.puredata.info/pipermail/pd-list/2011-08/090196.html

Definitely check out Bryan Jurish's moocow with its bytes2any and any2bytes. They work quite nicely for converting between messages
and lists of byte floats and are easy to use.

I only want to use externals that I can guarantee every user who I
distribute my patches to will have, or can easily get, including
people on mobile devices. Do those externals compile with your
Makefile-template?

The moocow externals have a separate, custom automake build system.
They are also included with Pd-extended. Pd-extended was created with
this idea as the central focus, it is a standard distribution of a
whole collection of libraries.

.hc

                         kill your television

Yeah, [s2l], that's the one I knew it existed but couldn't remember. But what I didn't expect is that it'd work so well for this :)

But I also always try to see if it's possible to do with vanilla objects, and have a vanilla patch version. I was so convinced it'd be impossible, but Jonathan proved it can be done. Wow, I'm still trying to understand how it works, incredible.

Thanks folks

2011/8/3 Jonathan Wilkes jancsika@yahoo.com

Aw c'mon, Miller, you didn't even try.

It's just a little sprintf hacking and that idiosyncratic recursion that outputs everything backwards.

-Jonathan

---

*From:* Miller Puckette msp@ucsd.edu *To:* Alexandre Torres Porres porres@gmail.com *Cc:* pd-lista puredata pd-list@iem.at *Sent:* Wednesday, August 3, 2011 12:35 AM *Subject:* Re: [PD] (breaking symbols) was Re: find a list of numbers in a text file

Nope... there needs to be a string-to-binary-list-and-back function somewhere but I can't figure out what to name it :)

M

On Wed, Aug 03, 2011 at 01:26:21AM -0300, Alexandre Torres Porres wrote:

...

now, some files come in ratios as one symbol like this

5/4 3/2 7/4

I'd need to break them into different characters, then treat as numbers

to

...

get interval in cents. How do I do that? I believe I can't do it in any

way

...

with vanilla objects, right?

thanks Alex

2011/8/3 Alexandre Torres Porres porres@gmail.com

...

yeah, it works :)

I knew there had to be an easier way other than the mess I did.

Perfect, Thanks

This is a very cool addon feature to my stuff I'm showing at PdCon, see

you

...

...

all there.

See you all there soon!

2011/8/3 Miller Puckette msp@ucsd.edu

...

HI Alex --

Have you tried sending textfile an "open [my-filename] cr" message?

The

...

...

...

"cr" flag asks to interpret newlines as end-of-list.

cheers Miller

On Tue, Aug 02, 2011 at 11:51:17PM -0300, Alexandre Torres Porres

wrote:

...

...

...

...

Hi folks

Back in the end of my masters, I did make something that allows you

to

...

...

...

load

...

scales from the Scala software into Pd, which has a database of over

4000

...

scales.

Check the software and data bank here

http://www.huygens-fokker.org/scala/

...

It's an extremely powerful tool for microtonality, but you may not

care

...

...

...

for

...

that and just want to use the scale data bank in Pd.

Anyway, I have a way that exports the from the Scala software into

a

...

...

...

text

...

file that opens in this specific subpatch of mine.

But I was trying to do something easier, and that is just load these

*.scl

...

files into [textfile] or [msgfile] for example, and extracting the

list

...

...

...

of

...

these scale intervals in cents.

Here's what one of these files look like

==============

! 08-11.scl ! 8 out of 11-tET 8 ! 218.18182 327.27273 436.36364 654.54545 763.63636 872.72727 1090.90909 2/1

===============

So I assumed it'd be easy to extract each cents value and make a

list

...

...

...

out of

...

it, but I was wrong. Don't know why but it doesn't load this in

separate

...

...

...

...

lines, maybe because it is not a *.txt file at all.

And anyway, I'm getting in Pd just a list, so the above file, for

example,

...

file becomes

list ! 08-11.scl ! 8 out of 11-tET 8 ! 218.182 327.273 436.364

654.545

...

...

...

...

763.636 872.727 1090.91 2/1

I seem to have found a messy way to get the list out of it, but

maybe

...

...

...

you

...

people know of something really simple and elegant with some

extended

...

...

...

...

objects.

Thanks Alex

...

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->

http://lists.puredata.info/listinfo/pd-list

...

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->

http://lists.puredata.info/listinfo/pd-list

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On Wed, 3 Aug 2011, Jonathan Wilkes wrote:

The idiosyncratic recursion happens when combining the single digits to make the final two values of the numerator and denominator.  It's a [list split 1] with the middle outlet to a [t a] that feeds back into the left inlet.  This outputs the list backwards-- I'm not exactly sure why, but it's handy in this case because I can just multiply each digit by increasing powers of ten and accumulate to get the final value for the numerator.  (Same process for the denominator.)  There's the danger of a stack overflow, but it's unlikely that either part of the fraction would have more than 249 digits.

I think I had made such a recursion in an intermediate version of [list-drip] that I didn't publish, which might have been a bit faster, but having a limit of 200 or 300 levels wasn't fine at all. Who would I be to say that people can't have uses for more elements than that ? That's why I made a half-half splitter which uses only log2(n) recursion levels, which means it's only one more level for each time you double the list size.

Actually now that I look at it, there should be a much greater danger of a stack overflow in the outer loop, because there are seven objects involved in the recursion. Not sure I understand the relationship between # of objects in recursive chain and max # function calls before stack overflow.

Yeah, for Pd, it's a matter of maximum number of levels of calls, whereas for the OS, what matters is the total size in bytes. You'll normally reach Pd's limit a lot faster. The number of levels of calls is the number of calls per recursion times the number of recursions.

IIRC, much older versions of Pd used a stack size check in bytes, but it caused problems real quickly. I don't remember whether the change had to do with the introduction of the [list] classes, which use stack-allocated buffers.

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

I don't understand what you're saying about receive symbols.  How do you get the single characters in the first place?

-Jonathan

---

From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Miller Puckette msp@ucsd.edu; Alexandre Torres Porres porres@gmail.com; pd-lista puredata pd-list@iem.at Sent: Thursday, August 4, 2011 12:03 PM Subject: Re: [PD] (breaking symbols) was Re: find a list of numbers in a text file

On Wed, 3 Aug 2011, Jonathan Wilkes wrote:

...

Aw c'mon, Miller, you didn't even try. It's just a little sprintf hacking and that idiosyncratic recursion that outputs everything backwards.

You can greatly speed it up by registering one receive symbol per character, such as [r $0-char-1], [r $0-char-2], [r $0-char-/], etc., because then you're using receiver-lookup as a table of characters.

There's no limit to the possibilities of making silly implementations on top of a silly base. There aren't any pd interpreters that both correctly understand what $1 means and can't load standard <m_pd.h> externals.

---

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

Anyone who would get scared off by the gymnastics/spaghetti of that patch would already have been scared off by the lack of clean symbol manipulation tools in Pd vanilla.

Your original design failed because you ignored the ease with which people can ignore the innards of a much needed abstraction.  Abstractions are powerful because they don't require the author to know another language, and they can immediately be distributed to any platform on which Pd runs.  Anyone who saw your list-drip-quick attachment on the list could make use of it right away in a patch.

-Jonathan

---

From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Miller Puckette msp@ucsd.edu; Alexandre Torres Porres porres@gmail.com; pd-lista puredata pd-list@iem.at Sent: Sunday, August 7, 2011 2:18 PM Subject: Turing Tarpit (was Re: (breaking symbols))

On Thu, 4 Aug 2011, Jonathan Wilkes wrote:

...

I don't understand what you're saying about receive symbols.  How do you get the single characters in the first place?

Oh, nevermind. Just a silly mistake of mine.

Anyway... I think that all this kind of thing will do, is scare off any potential pd users that like clean designs... I mean, such patches are quite skilled,

but wouldn't it be nice if such skills could concentrate more on things that aren't Turing Tarpit Voodoo Dance.

http://en.wikipedia.org/wiki/Turing_tarpit

It does scare me that my [list-drip] is more used than my [foreach]. Both do the same thing, but [list-drip] is more twisted, much slower than [foreach], and I originally designed it to show how ridiculous things can get when trying to be efficient while sticking to what plain vanilla 42 has to offer. The answer is that what is considered the standard class library (used by everybody) has to grow faster than what someone is willing to do. Few people have the luxury of holding back additions to core software while pondering a few years on how to name them.

I consider my [list-drip] to be a small improvement over the older [list-drip]. The big improvement is when people will stop insisting on using an

abstraction for doing something that ought to be written in C.

---

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

On 11/24/14, Billy Stiltner billy.stiltner@gmail.com wrote:

with the new list from symbol I send 50/40 split at / , removed / then to symbol one list tosymbol spits out out symbol '50' and other list tosymbol spits out symbol '40'

how in the world do I strip the symbol selector and send 50 and 40 to [/ ] as floats?

found it in this subject, Thanks ChrisMac

Hi,

Billy Stiltner schrieb am 24.11.2014 13:11:

how in the world do I strip the symbol selector and send 50 and 40 to [/ ] as floats?

One way is using [symbol2list] from zexy and then use a [float]:

[s2l] | [f]