Right now if I want to join "symbol A" and "symbol B" to get: "symbol AB", I can:

• use [mergefilename] from iemlib, or [sprintf] from cyclone or use a [string.join] from ceammc.
• Or I can make a list and have a "$1$2" message box... but message won't make it usable with extendable list.
• vanilla abstraction [l2s] could not do it because it will need a delimiter symbol and will return A/B for instance...

So is there a [mergefilename] vanilla abstraction somewhere?

For each element of the list, you can do [$1$2( where $1 is the previous output (or empty symbol at the beginning), and $2 is the next element of the list.

Not as fast as doing it with an external, but if you know your upper bound for your list size you can measure the worst-case and it may perform well enough for your use-case.

Someone can probably do an example patch of this.

@60hz I use [list store] and the [append $1( message, you need to bang it to get output, but generally there is a way to work the logic to take care of that for you, even when the number of elements is unknown. Hard to say without more information.

@oid Thanks, but this is for list... I need to do it on symbol.

@jancsika I see, I remermber that I did something like that not so long time ago but with [list fromsymbol]. But this simple symbol concatenation is a bit missing in pd.

But this simple symbol concatenation is a bit missing in pd.

One reason to be a bit cautious about adding it atm is that there is an internal limitation imposed on the length of symbols in lots of places throughout the source code.

And that limitation is helpful-- even the process of creating a symbol in Pd requires stepping through each character of the string itself.

So if someone created a beautiful text processing library that worked on Pd symbols, you'd hit all these weirdo problems with performance. Even printing stuff to the Pd Window to debug would be problematic because the symbols would be truncated to 1000 characters.

@60hz Yeah, you would use [list fromsymbol] before so you can easily parse the data, [list store] is to reconstruct the list and then back to a symbol with [list tosymbol] , this makes it extendable.

Edit: This also requires you to drip the list before the list store, which is not always best but works well for my needs but sometimes I just dump the list into an array whose size is controlled by [list length]. Depends on my exact needs at the time.

@60hz This is probably what @oid meant:

combinesymbols.pd

@60hz And here is a version using [makefilename]:

combinesymbols2.pd

@ingox Close enough anyways, I lacked energy to make up an example this morning. Never knew about [list prepend append], another one of the undocumented features, at least not in the help, perhaps in the manual. Useful.

@oid Well, it is just [list prepend] prepending the word "append".

@60hz Using a message with $1$2 is also possible, but maybe a bit clunky, as it needs a filter against "argument out of range" for the first item:

combinesymbols3.pd

@ingox Thinking has not worked out very well for me today.

yes, thanks all!
I will make an abstraction of it right now

@60hz The one with [list fromsymbol] is the fastest.

thanks for this, this is exactly what i was looking for!

i used @ingox combinesymbols.pd from reply #6, but added
[list append 32] before [list prepend append] to add spaces in between the elements.

results are much like [cyclone/tosymbol].

cheers!

A generalized abstraction that allows any characters between list elements.

concat.zip

@Remork said:

i used @ingox combinesymbols.pd from reply #6, but added
[list append 32] before [list prepend append] to add spaces in between the elements.

hadn't thought about the fact that it also adds a space at the end.
this version avoids that.

combinesymbols3.pd

only gripe is that it's still not happy processing floats or ints.

maybe just use the [concat] above

Here a version of [concat] that supports floats in both the list and the fill:

concat.zip

wow. this is solving all kinds of problems.
thank you so much!