Am 30. Oktober 2014 03:47:40 MEZ, schrieb Chris McCormick :
>
>Or maybe oscparse and tosymbol should do the expected thing when a
>float-looking symbol pops out?
Imho, an osc-path "/0" holds a symbol "0" (or rather: an osc-path only ever
consists of symbols).
So [oscparse] should try not be s
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
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 "makefi
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 accep
On 29/10/14 12:51, Chris McCormick wrote:
> Incidentally, my eyes might be deceiving me but it seems like
> pdfloat_float() is defined twice in x_connective.c(.)
Ridiculous. I am my own gremlin. Sorry for the noise!
Cheers,
Chris.
--
http://mccormick.cx/
__
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 t
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
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
wrote:
>Sorry if this patch gives you nightmares:
>
>[bang(
>|
>[oscformat 0]
>|
>[oscparse]
>|
>[set $1, bang(
>|
>[ (
>|
>[print]
>
>Hit the bang, and t
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/1
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.
Cheer
On Die, 2014-10-28 at 08:55 -0700, Jonathan Wilkes wrote:
> 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 co
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 no
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" wo
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 yo
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
aga
>
> 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 wrote:
> Hi Joe,
>
> the "0" in the OSC address part actually is a symbol!
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 ro
Hi,
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
[route] objects down the line.
For example a message: "/tag /0 /example 0.45" will not be correctly parsed
with the following:
[oscparse]
|
[list t
18 matches
Mail list logo
