Re: [PD] [pii2c] keeps and resends previous messages when addresses change

[Alexandros]

It seems that it is indeed a Wire library issue as it doesn't play nice
with Teensy 3.x. In this thread

from the Teensy forum it is mentioned that the same issue with mine
appeared and switching to i2c_t3 lib solves it.

As I wrote to you personally, I didn't check your code as I don't have a
Teensy 3.x at hand, but from your message and the thread I posted above
it seems that i2c_t3 is the solution (for the list, Martin's code uses
i2c_t3 instead of Wire).

Thanks again!

On 24/9/20 6:27 μ.μ., Martin Peach wrote:
> I uploaded a new version of [pii2c] yesterday via deken. It has some
> slight changes, (mainly adding optional address to the read message).
> I still don't get the double sends. I attach my code for teensy that
> listens on all the addresses. When I try your patch with it, the
> teensy only receives on the intended address. If I do 'i2cdetect -y 1'
> in the terminal it receives on all addresses 0x03-0x77.
>
> Martin
>
>
> On Wed, Sep 23, 2020 at 11:49 AM Martin Peach  wrote:
>> Before I test this, I notice you use Wire for the i2c slaves. Wire is
>> known to not work properly in slave mode.
>> I use this library for teensy i2c, it works very well:
>> https://github.com/nox771/i2c_t3
>> But I'll try your code later and see what I get.
>>
>> Martin
>>
>> On Wed, Sep 23, 2020 at 3:40 AM Alexandros  wrote:
>>> Sorry for coming back to this thread after so long, didn't have a Pi at
>>> hand. I have attached a very simple patch which reproduces the bug.
>>> You'll need to connect two I2C slave Teensy LC to the Pi. I have also
>>> attached the two Arduino files that should be loaded to the Teensies.
>>>
>>> What happens with this setup is that the Teensy that listens to 0x09
>>> (i2c_mess2.ino file) receives messages even when something is sent to
>>> 0x0A. The Teensy that listens to 0x0A (i2c_mess1.ino file) doesn't seem
>>> to be receiving anything.
>>>
>>> One Teensy prints to the serial console and the other responds by
>>> lighting up and turning off the LED on pin 13.
>>>
>>> On 12/9/20 11:02 μ.μ., Martin Peach wrote:
 On Thu, Sep 10, 2020 at 2:25 PM Alexandros  wrote:
> When trying to send messages to two I2C slaves from the Pi with [pii2c]
> the following happens:
>
> If I send this message to [pii2c 0x0A]:
> "write 3 127 7"
>
> it arrives properly at the slave address 0x0A.
>
> If I change the address to 0x09 with the message "addr 0x09" and then
> send this message:
> "write 97"
>
> then both messages will be sent to the respective slaves, meaning that
> "3 127 7" will be sent to slave 0x0A and "97" to slave 0x09. If I then
> change the message sent to 0x09 to "98", this will be sent to 0x09, but
> again "3 127 7" will be sent to 0x0A. If I resend "3 127 7" to 0x0A,
> "98" (the last message set to 0x09) will be sent to 0x09 as well.
>
> The same behavior occurs when I send the message "write 0x09 98". The
> same behavior also occurs if I use two different [pii2c] objects, like 
> this:
>
> [write 3 127 7(
> |
> [pii2c 0x0A]
>
> [write 97(
> |
> [pii2c 0x09]
>
>
 Hmmm I don't get this. Do you have a patch that will reproduce the bug?
 (I am also able to send messages longer than 32 bytes, with
 MAX_I2C_BUF_SIZE 64 in my copy of pii2c.c.)
 I used a teeny 3.2 as a slave (using i2c_t3 from
 https://github.com/nox771/i2c_t3) listening on all addresses. It only
 receives the messages on the addresses I set in the Pd patch.

 Perhaps you have a hidden [pii2c 0x0A] somewhere that is also
 receiving your write messages.
 Since [pii2c] is using the same memory space for each message any new
 message will effectively erase the old ones, so it's hard to explain
 two different messages coming from a single object.

 Martin
___
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]

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] Route "1" instead of 1

[IOhannes m zmoelnig]

On 2020-10-01 11:48, Maximiliano Estudies wrote:
> Dear List,
> 
> is there a way to tell [route] to route the symbol "1" insead of (float) 1?
> I'm working with OSC and the incoming messages have a lot of numbers (like
> /track/1/fxparam/1/) in the namespace. For now I have been using
> 
> [list split 1]
> | |
> [f ]  |
> | |
> [list append]


like this:


|
|   [loadbang]
|   [1(
|   [makefilename %d]
|   |
[route x]
|

but this is only convenient, if you don't want to match many different
number-symbols.

another version of yours, which should perform slightly better (as it
doesn't need to run [list append] just to strip the head away in the
following [route] is):

|
[tl s]
||
[list split] |
|[float]
|[== 1]
||
[spigot  ]
|

gfmdasr
IOhannes


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

Re: [PD] Number of the available midi ports shown

[Maximiliano Estudies]

there is already one (#1110
)

El jue., 1 oct. 2020 a las 11:33, IOhannes m zmoelnig ()
escribió:

> On 2020-09-29 19:23, Maximiliano Estudies wrote:
> > Would it be possible to extend the drop-down menu to all the devices?
>
>
> please open a ticket on https://bugs.puredata.info/
> (if there isn't one already)
>
> gmdsfrt
> IOhannes
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>


-- 
Maximiliano Estudies
*VDT Referat Beschallung*
+49 176 36784771
omslo.com
maxiestudies.com
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Route "1" instead of 1

[Maximiliano Estudies]

Dear List,

is there a way to tell [route] to route the symbol "1" insead of (float) 1?
I'm working with OSC and the incoming messages have a lot of numbers (like
/track/1/fxparam/1/) in the namespace. For now I have been using

[list split 1]
| |
[f ]  |
| |
[list append]

to convert the symbols to floats, which is actually fine, but I have a big
project coming up where I will have to do this a lot and maybe there is a
way to ask [route] politely to recognize the symbol "1".

Cheers,
-- 
Maximiliano Estudies
*VDT Referat Beschallung*
+49 176 36784771
omslo.com
maxiestudies.com
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Number of the available midi ports shown

[IOhannes m zmoelnig]

On 2020-09-29 19:23, Maximiliano Estudies wrote:
> Would it be possible to extend the drop-down menu to all the devices?


please open a ticket on https://bugs.puredata.info/
(if there isn't one already)

gmdsfrt
IOhannes


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

Re: [PD] Number of the available midi ports shown

[Maximiliano Estudies]

Thanks for your answer Dan! I didn't know about the patchbay, I just tried
it and it is great, but it doesn't solve my problem. If the ESI Interface
is plugged (which of course must be in order to be seen by the patchbay) it
is also seen by Pd and still takes space in the drop-down menu, even if I
don't use it at all.

El mié., 30 sept. 2020 a las 12:24, Dan Wilcox ()
escribió:

> I'd recommend not choosing inputs directly in Pd, but use IAC MIDI busses
> and then route the hard device to them with something like MIDI Patchbay. I
> use this all the time, but then again I am not using as many simultaneous
> interfaces as you are.
>
> http://notahat.com/midi_patchbay/
>
> On Sep 30, 2020, at 12:11 AM, pd-list-requ...@lists.iem.at wrote:
>
> Date: Tue, 29 Sep 2020 19:23:00 +0200
> From: Maximiliano Estudies 
> To: Pd-List 
> Subject: [PD] Number of the available midi ports shown
> Message-ID:
> 
> Content-Type: text/plain; charset="utf-8"
>
> Dear list,
>
> I recently stumbled on a problem with the number of available midi
> interfaces shown under _midi settings_. I am using four different
> keyboards, three of them connected via USB Midi and one over a ESI M8U Midi
> interface. I also need 4 internal IAC MIDI Buses.
> My problem is that the ESI interface has 16 ports that are shown as
> different devices, and Pd shows only the first 21 available devices, so
> when the interface is connected I can't select some of the other keyboards
> as inputs because they are not shown in the drop-down list.
> I only need the first port of the ESI interface and I can't disable the
> rest in the audio-midi config, and this is the only interface I have.
> Would it be possible to extend the drop-down menu to all the devices?
> I'm using Pd-0.50 on OSX Sierra (10.12).
>
> Cheers,
> Maxi
>
>
> 
> Dan Wilcox
> @danomatika 
> danomatika.com
> robotcowboy.com
>
>
>
>

-- 
Maximiliano Estudies
*VDT Referat Beschallung*
+49 176 36784771
omslo.com
maxiestudies.com
___
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