It seems this could be an issue in how the object parses integers and strings

Sorry yep I meant symbols instead of strings there :)

Thanks for the fix Frank!

Cheers, Joe

On 13 October 2014 14:40, Frank Barknecht fbar@footils.org wrote:

Hi Joe,

the "0" in the OSC address part actually is a symbol! All parts of an OSC address are strings as far as [oscparse] and [oscformat] are concerned.

Try this:

[bang( | [oscformat 0] | [oscparse] | [print]

It will print "symbol 0"!

[route 0] is a [route] in "float-mode": It only routes float messages, that's why it cannot catch symbol-messahes with a numeric symbol data part.

You should be able to work around this by creating a [route] in symbol-mode and feeding it a symbol-0 to the right inlet like this:

                [0(
                |
                [makefilename %d]
                |

[route DUMMY-SYMBOL]

Ciao

Frank

On Mon, Oct 13, 2014 at 12:34:24PM +0100, Joe White wrote:

...

I noticed with the [oscparse] object that if I have an address pattern

that

...

contains only an integer, it can't be correctly parsed by any future

Ciao

Frank Barknecht _ ______footils.org__

---

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

Hi Chris,

I think, for the way back some external based on atoi(3) or atof(3) is needed. I'm pretty sure someone has made one already. The "0" in the printed "symbol 0" is a real symbol atom itself, just like the word "zero" would. One could [select] it, but if you don't know what symbol-number youmight get, only atoX can convert back, I believe. But I might be wrong ...

All the best,

Frank

On Sun, Oct 26, 2014 at 10:02:17PM +0800, Chris McCormick wrote:

Hi Frank,

On 13/10/14 21:40, Frank Barknecht wrote:

...

[bang( | [oscformat 0] | [oscparse] | [print]

It will print "symbol 0"!

Seems you can do this with "list tosymbol" and also "makefilename %d" - any idea how I can get from one of those symbols back to a proper float again? I am sure I should know this by now!

Cheers,

Chris.

-- http://mccormick.cx/

In pd_typedmess of m_class.c, the float handler will currently throw an error if the arg isn't a float atom. However, this could be changed so that if the arg is a symbol-atom Pd sends it through a binbuf "carwash" to check if it comes out as a float. If so, it could send it on its way. If not, it would throw the same error it currently does.

So

[0( | [makefilename %d] | [float $1( | [route float] | [print success]

This wouldn't add any overhead to Pd's current message-dispatching system, as the conversion would only get triggered for symbol-args which currently throw an error.

-Jonathan

On Tuesday, October 28, 2014 7:06 AM, Roman Haefeli reduzent@gmail.com wrote:

On Tue, 2014-10-28 at 09:21 +0100, Frank Barknecht wrote:

Hi Chris,

I think, for the way back some external based on atoi(3) or atof(3) is needed. I'm pretty sure someone has made one already. The "0" in the printed "symbol 0" is a real symbol atom itself, just like the word "zero" would. One could [select] it, but if you don't know what symbol-number youmight get, only atoX can convert back, I believe. But I might be wrong ...

I know of at least two ways to convert symbolic numbers into real floats, but none of them is really satisfying. One is to save the symbol or list containing symbolic numbers with [textfile] and re-read the file afterwards. The other one is sending such a symbol/list through [netsend]/[netreceive]. I consider them not satisfying because it either involves an unnecessary file system access (and there is no save temporary path that works across platforms), the other one is not execution order safe.

How about a [list eval], that would re-evaluate the incoming list and would consider only its plain content while disregarding the used atom types. Does that make sense?

Roman

On Sun, Oct 26, 2014 at 10:02:17PM +0800, Chris McCormick wrote:

...

Hi Frank,

On 13/10/14 21:40, Frank Barknecht wrote:

...

[bang( | [oscformat 0] | [oscparse] | [print]

It will print "symbol 0"!

Seems you can do this with "list tosymbol" and also "makefilename %d" - any idea how I can get from one of those symbols back to a proper float again? I am sure I should know this by now!

Cheers,

Chris.

-- http://mccormick.cx/

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

Hi,

On 28/10/14 16:21, Frank Barknecht wrote:

I think, for the way back some external based on atoi(3) or atof(3) is needed.

I made the attached monstrosity as an abstraction.

Agree this probably needs a native implementation and I think it probably belongs inside Pd like Jonathan said.

Cheers,

Chris.

Hi Miller,

Yeah but try replacing the 'print' with a float box.

Cheers,

Chris.

On October 29, 2014 12:22:47 PM GMT+08:00, Miller Puckette msp@ucsd.edu wrote:

Sorry if this patch gives you nightmares:

[bang( | [oscformat 0] | [oscparse] | [set $1, bang( | [ ( | [print]

Hit the bang, and the empty message box gets a "0", and the print says, "0".

cheers Miller

On Sun, Oct 26, 2014 at 10:02:17PM +0800, Chris McCormick wrote:

...

Hi Frank,

On 13/10/14 21:40, Frank Barknecht wrote:

...

[bang( | [oscformat 0] | [oscparse] | [print]

It will print "symbol 0"!

Seems you can do this with "list tosymbol" and also "makefilename %d"

...

any idea how I can get from one of those symbols back to a proper

float

...

again? I am sure I should know this by now!

Cheers,

Chris.

-- http://mccormick.cx/

---

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

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

Hi Miller,

On 29/10/14 12:34, Miller Puckette wrote:

Oops, you're right, that acomplished nothing but deeper confusion.

There should be a way to convert strings <-> floats in vanilla without making a monstrous ascii-parsing patch. Seems like this shouldn't happen automatcally (99% of teh time it's probably a mistake) but there should be a way to do it when you actually want to...

One alternative would be to make the [f] object accept a subset of symbols that look like floats so that a user can do an explicit typecast, printing an error in the event a symbol does not convert cleanly. Would you hypothetically accept a patch that did that?

Incidentally, my eyes might be deceiving me but it seems like pdfloat_float() is defined twice in x_connective.c(.)

Cheers,

Chris.

Hi Miller,

On 29/10/14 12:51, Chris McCormick wrote:

One alternative would be to make the [f] object accept a subset of symbols that look like floats so that a user can do an explicit typecast, printing an error in the event a symbol does not convert cleanly. Would you hypothetically accept a patch that did that?

Patch for this is here, just incase:

http://sourceforge.net/p/pure-data/patches/535/

Thanks for your consideration. Feedback welcome of course!

Cheers,

Chris.

On 29/10/14 23:45, Miller Puckette wrote:

Yeah, I thought about doing that - but ran into trouble because thn really "sybol" should do the opposite but symbol already does something else (perhaps appropriately outputs the symbol "float".)

"Trigger" simlarly already defined.

Horribly, the opposite (float to symbol) is doable using "makefilename".

Also using a) oscformat/oscparse and b) list fromsymbol/tosymbol both of which I feel slightly responsible for. :)

I understand the asymmetry. Maybe there should be a "cast" object? Or an "makefloat" object?

Or maybe oscparse and tosymbol should do the expected thing when a float-looking symbol pops out?

Cheers,

Chris.