Re: [PD] Concatenating two atoms into one?

[Maximiliano Estudies]

To add to the great explanations already given by Johannes and Christoph,
Miller gave a seminar last spring quarter called "Inside Pd" where he
explains the inner workings of Pd in great detail.
Here is the course site:
http://msp.ucsd.edu/syllabi/206.20s/index.htm
and here the videos:
http://msp.ucsd.edu/syllabi/206.20s/movies/
In the video 2b.apr10.mp4
 he explains the
symbol storage strategy.

I'm very grateful to be able to access this content, thank you Miller!

El jue., 1 oct. 2020 a las 13:21, Christof Ressi ()
escribió:

> > your computer memory will define the time when it will crash Pd (it will
> > crash, when all the strings in the symboltable eat up all the memory
> > available)
> I think eating up all available memory is not a likely scenario on
> modern computers with a 64-bit address space and virtual memory.
>
> The actual problem is that Pd's symbol table is implemented as a hash
> table with seperate chaining
> (https://en.wikipedia.org/wiki/Hash_table#Separate_chaining). This means
> that symbols which have the same hash value (= hash collision) are
> connected as a linked list. If you look up a such a symbol, you have to
> walk the linked list and do a string comparison for each element until
> you find a match.
>
> The more symbols you add, the more hash collisions you get and the more
> symbols end up in the same bucket. In practice, this means that for a
> large number of elements, insertion and lookup becomes more and more
> expensive because the linked lists for each bucket grow larger and
> larger. While the hash lookup takes constant time "O(1)", the linked
> list traversal takes linear time "O(N)" (and is not very cache friendly).
>
> Good hash table implementations mitigate this problems by a technique
> called "rehashing" where the hash table array is resized if the "load
> factor" (number of elements / number of buckets) exceed a certain
> threshold (= "load factor"). Then every item is hashed again and
> inserted back into the new hash table.
>
> Unfortunately, Pd doesn't do any rehashing and it is certainly possible
> to significantly slow down Pd by flooding the symbol table. A common
> load factor threshold is 0.75, but if you create 10 000 unique symbols
> in Pd, the load factor would be ~10! Not very good...
>
> In fact, I've already been thinking about improving the symbol table.
>
> Christof
>
> On 01.10.2020 10:28, IOhannes m zmoelnig wrote:
> > On 2020-10-01 09:54, oliver wrote:
> >> IOhannes m zmoelnig wrote:
> >>> On 2020-10-01 09:22, hans w. koch wrote:
>  but be aware of the risks of invoking makefilname all too often.
> >>> note that if you use dollsyms (as in `[$1$2(`) you are filling up the
> >>> symbol table just as well.
> >> i was just about to ask, if the attached modified patch would avoid that
> >> problem, but you replied already.
> >>
> >> could you please clarify the used term "invoke" a bit ?
> >> i guess the number of [makefilename] objects isn't the problem, but how
> >> much/often its conversion mechanism is used, right ?
> > yes (the latter).
> >
> >> does that mean that everytime a number->symbol conversion happens
> >> (regardless how it is done) the symboltable is filled and will
> > no.
> > everytime a *new* symbol is created.
> > the point of symbols (vs ordinary strings) is, that a single literal
> > only needs to be stored once.
> > so if you first create a string "rubadub" (however you do this), a new
> > entry for the symbol 'rubadub' is created.
> > now, if you concatenate the symbols 'rubad' and 'ub', the result is
> > "rubadub", which already happens to be in the symbol table (and thus no
> > new entry needs to be generated).
> > for Pd these strings are *identical*.
> > this is cool as we can really easily compare the two strings. if they
> > occupy the same entry in the symbol table (which basically means, that
> > Pd gets the same pointer for when turning the literal into a symbol),
> > then the two strings are the same.
> > so rather than having to compare each character of the string
> > "sjfdjdasjfsfjrueincru057894_curtrfenr3ewf8354j3wp57jp3" with each
> > character of "sjfdjdasjfsfjrueincru057894_curtrfenr3ewfB354j3wp57jp3" ,
> > Pd only needs to compare two pointers - and this can be done in a single
> > step on your CPU.
> >
> > the problem with generating symbol programmatically (e.g. by sending
> > numbers to [makefilename %d]) is, that it is so super easy to generate
> > lots and lots of (different) symbols.
> >
> >
> >> eventually slow down or crash PD ?
> >>
> >> so, as a live example: writing number values to GUI labels dynamically
> >> is a potentially dangerous thing ? what's the threshold there ?
> > your computer memory will define the time when it will crash Pd (it will
> > crash, when all the strings in the symboltable eat up all the memory
> > available)
> >
> > as for the slow-down, why not simply create a patch that tests this for
> you?
> >
> > 

Re: [PD] Concatenating two atoms into one?

[jayrope]

doubled-checked here (pd 0.50-2, osx 10.9.5)

[set $1$2, bang(

outputs $1$2 to a subsequent message object [2] here. However banging
this one causes no subsequent output to a number or symbol object [3]
afterwards, neither from [set $1$2, bang( directly, nor from an
independently fired bang to [2].

Patch-save and reload does *not* change anything here, as opposed to
what Matt reports.

So, is that a bug - or expected behaviour?

If expected behaviour, why would that be so?

Thank you again for your insights.

janek


On 10/01/20 11:14, pd-list-requ...@lists.iem.at wrote:
> Date: Thu, 1 Oct 2020 16:10:27 +0800
> From: Matt Davey 
> To: oliver 
> Cc: Pd-List 
> Subject: Re: [PD] Concatenating two atoms into one?
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> if you bang the 7 17 message, and then bang the message box that gets set,
> pd outputs to console:
> 
> float: no method for '717'
> 
> But if you then save the patch, reload, and bang that same message box, it
> outputs correctly.
> 
> Is that a bug?  Surely if behaviour is different between a live patch and a
> saved patch, that constitutes buggy behaviour?
> 
>> matt's  `[set $1$2, bang(` construct is really only useful if you want
> to send the data to a messagebox (but why would you want to do that?)
> 
> I often use [set $1, bang ( for things like setting a message box with the
> output of openpanel, and then also triggering the message.  Had no idea
> that it didn't work for floats.
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.puredata.info/pipermail/pd-list/attachments/20201001/7c81cef9/attachment-0001.html>
> -- next part --
> A non-text attachment was scrubbed...
> Name: tester.pd
> Type: application/octet-stream
> Size: 337 bytes
> Desc: not available
> URL: 
> <http://lists.puredata.info/pipermail/pd-list/attachments/20201001/7c81cef9/attachment-0001.obj>

-- 
jayrope
+++
jayrope.com
aircushionfinish.com
kliklak.net



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Concatenating two atoms into one?

[Christof Ressi]

your computer memory will define the time when it will crash Pd (it will
crash, when all the strings in the symboltable eat up all the memory
available)
I think eating up all available memory is not a likely scenario on 
modern computers with a 64-bit address space and virtual memory.


The actual problem is that Pd's symbol table is implemented as a hash 
table with seperate chaining 
(https://en.wikipedia.org/wiki/Hash_table#Separate_chaining). This means 
that symbols which have the same hash value (= hash collision) are 
connected as a linked list. If you look up a such a symbol, you have to 
walk the linked list and do a string comparison for each element until 
you find a match.


The more symbols you add, the more hash collisions you get and the more 
symbols end up in the same bucket. In practice, this means that for a 
large number of elements, insertion and lookup becomes more and more 
expensive because the linked lists for each bucket grow larger and 
larger. While the hash lookup takes constant time "O(1)", the linked 
list traversal takes linear time "O(N)" (and is not very cache friendly).


Good hash table implementations mitigate this problems by a technique 
called "rehashing" where the hash table array is resized if the "load 
factor" (number of elements / number of buckets) exceed a certain 
threshold (= "load factor"). Then every item is hashed again and 
inserted back into the new hash table.


Unfortunately, Pd doesn't do any rehashing and it is certainly possible 
to significantly slow down Pd by flooding the symbol table. A common 
load factor threshold is 0.75, but if you create 10 000 unique symbols 
in Pd, the load factor would be ~10! Not very good...


In fact, I've already been thinking about improving the symbol table.

Christof

On 01.10.2020 10:28, IOhannes m zmoelnig wrote:

On 2020-10-01 09:54, oliver wrote:

IOhannes m zmoelnig wrote:

On 2020-10-01 09:22, hans w. koch wrote:

but be aware of the risks of invoking makefilname all too often.

note that if you use dollsyms (as in `[$1$2(`) you are filling up the
symbol table just as well.

i was just about to ask, if the attached modified patch would avoid that
problem, but you replied already.

could you please clarify the used term "invoke" a bit ?
i guess the number of [makefilename] objects isn't the problem, but how
much/often its conversion mechanism is used, right ?

yes (the latter).


does that mean that everytime a number->symbol conversion happens
(regardless how it is done) the symboltable is filled and will

no.
everytime a *new* symbol is created.
the point of symbols (vs ordinary strings) is, that a single literal
only needs to be stored once.
so if you first create a string "rubadub" (however you do this), a new
entry for the symbol 'rubadub' is created.
now, if you concatenate the symbols 'rubad' and 'ub', the result is
"rubadub", which already happens to be in the symbol table (and thus no
new entry needs to be generated).
for Pd these strings are *identical*.
this is cool as we can really easily compare the two strings. if they
occupy the same entry in the symbol table (which basically means, that
Pd gets the same pointer for when turning the literal into a symbol),
then the two strings are the same.
so rather than having to compare each character of the string
"sjfdjdasjfsfjrueincru057894_curtrfenr3ewf8354j3wp57jp3" with each
character of "sjfdjdasjfsfjrueincru057894_curtrfenr3ewfB354j3wp57jp3" ,
Pd only needs to compare two pointers - and this can be done in a single
step on your CPU.

the problem with generating symbol programmatically (e.g. by sending
numbers to [makefilename %d]) is, that it is so super easy to generate
lots and lots of (different) symbols.



eventually slow down or crash PD ?

so, as a live example: writing number values to GUI labels dynamically
is a potentially dangerous thing ? what's the threshold there ?

your computer memory will define the time when it will crash Pd (it will
crash, when all the strings in the symboltable eat up all the memory
available)

as for the slow-down, why not simply create a patch that tests this for you?

create labels with [makefilename label%08d] with the input ranging from
0...200 (or so; you'll notice when it gets slow).
measure the time it takes to generate the symbols (well, measure the
time it takes to generate 1 symbols or)



or is there any way to clear the symboltable ?

i think i covered this in another ("the" other) post quite recently.


gfsdm
IOhannes


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




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

Re: [PD] Concatenating two atoms into one?

[IOhannes m zmoelnig]

On 2020-10-01 10:10, Matt Davey wrote:
> if you bang the 7 17 message, and then bang the message box that gets set,
> pd outputs to console:
> 
> float: no method for '717'
> 
> But if you then save the patch, reload, and bang that same message box, it
> outputs correctly.
> 
> Is that a bug?  Surely if behaviour is different between a live patch and a
> saved patch, that constitutes buggy behaviour?

no. not really.

- Pd has a strong distinction between numbers and symbols.
- however, Pd displays symbols and numbers the same. (there's no
*visual* clue that a text is a number or a symbol apart from it's
content). this is why you think that your "7"+"17" is a number in the
first place.
- when Pd parses a string into an atombuffer (this is what happens when
you load a patch), it will try to determine whether a given string is a
number of not. if it looks like a number, it will become a number. if it
doesn't, it will become a symbol. this is why 717 becomes a number after
loading.

so what you are seeing is a side-effect of how Pd works - which in turn
makes Pd able to get anything accomplished in a way that makes it usable
as a live system for playing on stage.
there are languages that don't make a distinction between numbers and
strings (like PHP). there's probably a reason why people don't use PHP
for realtime signal processing; and the automatic type coercion
(treating strings as numbers and vice versa, depending on the context),
is a source of much headache and bugs.

of course, one could tweak the fileformat a little bit, so that it will
indicate that "717" is really a symbol, and when you load the patch, it
will still look like a number, but still be a symbol (so you get the "no
method for '717'" again).

the problem with this is, that it will probably break a lot of patches.


> 
>> matt's  `[set $1$2, bang(` construct is really only useful if you want
> to send the data to a messagebox (but why would you want to do that?)
> 
> I often use [set $1, bang ( for things like setting a message box with the
> output of openpanel, and then also triggering the message.  Had no idea
> that it didn't work for floats.
it works fine. why would it not?

what you are doing with [set $1, bang( is:
- store the current value for later use
- show the current value
- use the current value right now

i'm also using this quite often.
however, my "why would you want to do that" was meant to say: this
doesn't do anything useful in the context of the question.

also note that "$1" and "$1$2" are two very different things.

fgmadrs
IOhannes


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

Re: [PD] Concatenating two atoms into one?

[IOhannes m zmoelnig]

On 2020-10-01 09:54, oliver wrote:
> IOhannes m zmoelnig wrote:
>> On 2020-10-01 09:22, hans w. koch wrote:
>>> but be aware of the risks of invoking makefilname all too often.
>>
>> note that if you use dollsyms (as in `[$1$2(`) you are filling up the
>> symbol table just as well.
> 
> i was just about to ask, if the attached modified patch would avoid that
> problem, but you replied already.
> 
> could you please clarify the used term "invoke" a bit ?
> i guess the number of [makefilename] objects isn't the problem, but how
> much/often its conversion mechanism is used, right ?

yes (the latter).

> 
> does that mean that everytime a number->symbol conversion happens
> (regardless how it is done) the symboltable is filled and will

no.
everytime a *new* symbol is created.
the point of symbols (vs ordinary strings) is, that a single literal
only needs to be stored once.
so if you first create a string "rubadub" (however you do this), a new
entry for the symbol 'rubadub' is created.
now, if you concatenate the symbols 'rubad' and 'ub', the result is
"rubadub", which already happens to be in the symbol table (and thus no
new entry needs to be generated).
for Pd these strings are *identical*.
this is cool as we can really easily compare the two strings. if they
occupy the same entry in the symbol table (which basically means, that
Pd gets the same pointer for when turning the literal into a symbol),
then the two strings are the same.
so rather than having to compare each character of the string
"sjfdjdasjfsfjrueincru057894_curtrfenr3ewf8354j3wp57jp3" with each
character of "sjfdjdasjfsfjrueincru057894_curtrfenr3ewfB354j3wp57jp3" ,
Pd only needs to compare two pointers - and this can be done in a single
step on your CPU.

the problem with generating symbol programmatically (e.g. by sending
numbers to [makefilename %d]) is, that it is so super easy to generate
lots and lots of (different) symbols.


> eventually slow down or crash PD ?
> 
> so, as a live example: writing number values to GUI labels dynamically
> is a potentially dangerous thing ? what's the threshold there ?

your computer memory will define the time when it will crash Pd (it will
crash, when all the strings in the symboltable eat up all the memory
available)

as for the slow-down, why not simply create a patch that tests this for you?

create labels with [makefilename label%08d] with the input ranging from
0...200 (or so; you'll notice when it gets slow).
measure the time it takes to generate the symbols (well, measure the
time it takes to generate 1 symbols or)


> 
> or is there any way to clear the symboltable ?

i think i covered this in another ("the" other) post quite recently.


gfsdm
IOhannes


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

Re: [PD] Concatenating two atoms into one?

[Matt Davey]

if you bang the 7 17 message, and then bang the message box that gets set,
pd outputs to console:

float: no method for '717'

But if you then save the patch, reload, and bang that same message box, it
outputs correctly.

Is that a bug?  Surely if behaviour is different between a live patch and a
saved patch, that constitutes buggy behaviour?

>matt's  `[set $1$2, bang(` construct is really only useful if you want
to send the data to a messagebox (but why would you want to do that?)

I often use [set $1, bang ( for things like setting a message box with the
output of openpanel, and then also triggering the message.  Had no idea
that it didn't work for floats.


tester.pd
Description: Binary data
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Concatenating two atoms into one?

[oliver]

IOhannes m zmoelnig wrote:

On 2020-10-01 09:22, hans w. koch wrote:

but be aware of the risks of invoking makefilname all too often.


note that if you use dollsyms (as in `[$1$2(`) you are filling up the
symbol table just as well.


i was just about to ask, if the attached modified patch would avoid that 
problem, but you replied already.


could you please clarify the used term "invoke" a bit ?
i guess the number of [makefilename] objects isn't the problem, but how 
much/often its conversion mechanism is used, right ?


does that mean that everytime a number->symbol conversion happens 
(regardless how it is done) the symboltable is filled and will 
eventually slow down or crash PD ?


so, as a live example: writing number values to GUI labels dynamically 
is a potentially dangerous thing ? what's the threshold there ?


or is there any way to clear the symboltable ?

sorry for my noob questions ... just a little concerned right now as i 
use this feature quite often ...


thanks for any insight !

best

oliver


#N canvas 601 150 479 319 12;
#X obj 31 53 hsl 128 15 1 4 0 0 empty empty empty -2 -8 0 10 -262144
-1 -1 0 0;
#X obj 178 53 hsl 128 15 1 4 0 0 empty empty empty -2 -8 0 10 -262144
-1 -1 0 0;
#X obj 175 76 t b f;
#X obj 349 54 loadbang;
#X msg 349 81 1;
#X text 345 28 initialize it;
#X obj 28 73 int;
#X floatatom 46 106 5 0 0 0 - - -;
#X text 27 23 VANILLA:;
#X obj 207 100 int;
#X obj 28 140 pack f f;
#X msg 28 167 symbol \$1\$2;
#X obj 28 193 float;
#X obj 28 217 change;
#X obj 28 244 print NO REPEATS;
#X connect 0 0 6 0;
#X connect 1 0 2 0;
#X connect 2 0 0 0;
#X connect 2 1 9 0;
#X connect 3 0 4 0;
#X connect 4 0 9 0;
#X connect 6 0 7 0;
#X connect 6 0 10 0;
#X connect 9 0 10 1;
#X connect 10 0 11 0;
#X connect 11 0 12 0;
#X connect 12 0 13 0;
#X connect 13 0 14 0;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Concatenating two atoms into one?

[IOhannes m zmoelnig]

On 2020-10-01 09:22, hans w. koch wrote:
> but be aware of the risks of invoking makefilname all too often.

note that if you use dollsyms (as in `[$1$2(`) you are filling up the
symbol table just as well.

gfmasdr
IOhannes


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

Re: [PD] Concatenating two atoms into one?

[IOhannes m zmoelnig]

On 2020-10-01 08:44, jayrope wrote:
> Thank you Hans and Matt,
> 
> Hans, nice workaround, I'll surely stick to this. Thank you.

i don't think this is a workaround.
it's rather the ideal solution, as it stays within the domain of
numbers, and doesn't require re-parsing the string (which is a costly
operation).

> 
> Matt, regarding banging the message: this unfortunately leads to the
> following object, for instance a float, reporting
> float: no method for '12' (i. e. no method for '').

use a symbol, not a selector (and make sure you are using Pd>=0.48)

matt's  `[set $1$2, bang(` construct is really only useful if you want
to send the data to a messagebox (but why would you want to do that?)

this should just work™:

[3.1 415(
|
[pack 0 0]
|
[symbol $1$2(
|
[float]
|
|3.1415\

but again, this is much more expensive than the solution proposed by hans.

gfmadrs
IOhannes


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

Re: [PD] Concatenating two atoms into one?

[hans w. koch]

but be aware of the risks of invoking makefilname all too often.
it may clutter the symboltable, as per this recent discussion (started by me 
and confirmed by johannes):
https://lists.puredata.info/pipermail/pd-list/2020-09/128158.html

best
hans


> Am 01.10.2020 um 08:46 schrieb oliver :
> 
> jayrope wrote:
>> Hello list,
>> I want to combine integer values from two sources into ONE new value,
>> preferably a number, just like
>> Source 1 sends 1, source 2 sends 1, result = 11
>> Src 3 sends 3, src 2 sends 8, result = 38
> 
> hi, here's my approach using [makefilename]
> 
> best
> 
> oliver
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list




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

Re: [PD] Concatenating two atoms into one?

[oliver]

jayrope wrote:

Hello list,
I want to combine integer values from two sources into ONE new value,
preferably a number, just like

Source 1 sends 1, source 2 sends 1, result = 11
Src 3 sends 3, src 2 sends 8, result = 38


hi, here's my approach using [makefilename]

best

oliver
#N canvas 601 150 479 526 12;
#X obj 31 53 hsl 128 15 1 4 0 0 empty empty empty -2 -8 0 10 -262144
-1 -1 10600 0;
#X obj 178 53 hsl 128 15 1 4 0 0 empty empty empty -2 -8 0 10 -262144
-1 -1 12700 0;
#X obj 28 212 float;
#X symbolatom 48 176 10 0 0 0 - - -;
#X obj 175 76 t b f;
#X obj 28 236 change;
#X obj 28 263 print NO REPEATS;
#X obj 349 54 loadbang;
#X msg 349 81 1;
#X text 345 28 initialize it;
#X obj 28 73 int;
#X floatatom 46 106 5 0 0 0 - - -;
#X obj 28 144 makefilename;
#X text 27 23 VANILLA:;
#X msg 207 125 set %d\$1;
#X obj 207 100 int;
#X text 136 154 see helpfile for [makefilename] ("multiple substitutions")
, f 32;
#X connect 0 0 10 0;
#X connect 1 0 4 0;
#X connect 2 0 5 0;
#X connect 4 0 0 0;
#X connect 4 1 15 0;
#X connect 5 0 6 0;
#X connect 7 0 8 0;
#X connect 8 0 15 0;
#X connect 10 0 11 0;
#X connect 10 0 12 0;
#X connect 12 0 3 0;
#X connect 12 0 2 0;
#X connect 14 0 12 0;
#X connect 15 0 14 0;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Concatenating two atoms into one?

[jayrope]

Thank you Hans and Matt,

Hans, nice workaround, I'll surely stick to this. Thank you.

Matt, regarding banging the message: this unfortunately leads to the
following object, for instance a float, reporting
float: no method for '12' (i. e. no method for '').

No value is put out.

j



On 10/01/20 04:23, Matt Davey wrote:
> can just bang a message box after setting it to flush the output, too.
> 
> like [set $1$2, bang (
> 





signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Concatenating two atoms into one?

[Matt Davey]

can just bang a message box after setting it to flush the output, too.

like [set $1$2, bang (
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Concatenating two atoms into one?

[hans w. koch]

how about just mulitplying source 1 by 10 and then adding to source 2?
or am i missing something? (patch attached)

hth

hans



combination.pd
Description: Binary data



> Am 01.10.2020 um 00:44 schrieb jayrope :
> 
> Hello list,
> I want to combine integer values from two sources into ONE new value,
> preferably a number, just like
> 
> Source 1 sends 1, source 2 sends 1, result = 11
> Src 3 sends 3, src 2 sends 8, result = 38
> 
> and so on.
> 
> Example patch below. A resulting message combines two values, but
> doesn't forward anything to a subsequent float or number object.
> (OSX 10.9.5, PD 0.50-2)
> 
> 
> #N canvas 405 254 606 341 12;
> #X obj 31 23 hsl 128 15 1 4 0 0 empty empty empty -2 -8 0 10 -262144
> -1 -1 1200 0;
> #X obj 178 23 hsl 128 15 1 4 0 0 empty empty empty -2 -8 0 10 -262144
> -1 -1 3900 0;
> #X obj 204 133 pack 1 1;
> #X obj 28 73 f;
> #X obj 28 43 i;
> #X obj 175 43 i;
> #X floatatom 186 229 5 0 0 0 - - -;
> #X msg 204 181 11;
> #X msg 204 157 set \$1\$2;
> #X obj 186 205 float;
> #X obj 175 79 t b b f;
> #X connect 0 0 4 0;
> #X connect 1 0 5 0;
> #X connect 2 0 8 0;
> #X connect 3 0 2 0;
> #X connect 4 0 3 0;
> #X connect 5 0 10 0;
> #X connect 7 0 9 0;
> #X connect 8 0 7 0;
> #X connect 9 0 6 0;
> #X connect 10 0 9 0;
> #X connect 10 1 3 0;
> #X connect 10 2 2 1;
> 
> 
> would appreciate a hint. Thanx very much in advance!
> 
> -- 
> jayrope
> +++
> jayrope.com
> aircushionfinish.com
> kliklak.net
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list

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

[PD] Concatenating two atoms into one?

[jayrope]

Hello list,
I want to combine integer values from two sources into ONE new value,
preferably a number, just like

Source 1 sends 1, source 2 sends 1, result = 11
Src 3 sends 3, src 2 sends 8, result = 38

and so on.

Example patch below. A resulting message combines two values, but
doesn't forward anything to a subsequent float or number object.
(OSX 10.9.5, PD 0.50-2)


#N canvas 405 254 606 341 12;
#X obj 31 23 hsl 128 15 1 4 0 0 empty empty empty -2 -8 0 10 -262144
-1 -1 1200 0;
#X obj 178 23 hsl 128 15 1 4 0 0 empty empty empty -2 -8 0 10 -262144
-1 -1 3900 0;
#X obj 204 133 pack 1 1;
#X obj 28 73 f;
#X obj 28 43 i;
#X obj 175 43 i;
#X floatatom 186 229 5 0 0 0 - - -;
#X msg 204 181 11;
#X msg 204 157 set \$1\$2;
#X obj 186 205 float;
#X obj 175 79 t b b f;
#X connect 0 0 4 0;
#X connect 1 0 5 0;
#X connect 2 0 8 0;
#X connect 3 0 2 0;
#X connect 4 0 3 0;
#X connect 5 0 10 0;
#X connect 7 0 9 0;
#X connect 8 0 7 0;
#X connect 9 0 6 0;
#X connect 10 0 9 0;
#X connect 10 1 3 0;
#X connect 10 2 2 1;


would appreciate a hint. Thanx very much in advance!

-- 
jayrope
+++
jayrope.com
aircushionfinish.com
kliklak.net



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list