[PD] how to write different types to [text]
Roman Haefeli
reduzent at gmail.com
Mon Mar 28 22:43:10 CEST 2022
On Sun, 2022-03-27 at 18:04 +0200, Christof Ressi wrote:
> On 27.03.2022 11:01, Roman Haefeli wrote:
> > On Sun, 2022-03-27 at 01:10 +0100, Christof Ressi wrote:
> > > In my experience, commas in [text] are broken... Best not to use
> > > them
> > > :-)
> >
> > What is the purpose of 'type' in [text] then? I find your advice of
> > not
> > using a feature because it is broken - frankly - disconcerting. If
> > it's
> > broken, then it ought to be fixed.
>
> Sure. I was a bit tongue-in-cheek :-)
>
> Currently, [text get] just strips all atoms after the first comma and
> outputs 1 (= colon) as the type. There is no way to get the rest of
> the message.
This is not what I experience. Commas don't wrap, so what comes after a
comma is still on the same line. However, [text get] and [text size]
are consistent in that they consider messages and not lines.
```
eins;
zwei;
drei, vier;
fuenf;
```
[text size] returns 5. [2(-[text get] returns 'symbol drei'. The
message after that is accessed with [3(-[text get].
> I think [text get] could simply output all sublists consecutively.
I think it does exactly that.
> By checking the right outlet you know if a message spans a whole line
> (= 0), or is part of a comma seperated list of messages (= 1).
>
> Another issue that you have mentioned is that we can't *set* lines
> that include actual commas. One simply solution could be to add a
> flag to [text set] that interprets the list as *escaped* text, just
> like [text fromlist]
>
> The only case where commas do already work is in [text sequence -g]:
>
> foo 1 2 3, bar baz
> This will indeed send the messages "1 2 3" and "bar baz" to
> destination "foo".
>
> > Apparantly, FUDI uses both, commas and semicolons. In message
> > boxes,
> > they have a different meaning. The selector of a message after a
> > semicolon is considered a send symbol. Everything after a comma i
> > considered simply a message.
>
> comma *atoms* always have that meaning. It just appears to be
> different depending on which level you look at it: "patch file" VS
> "patch"
>
> A Pd patch files is really just a sequence of messages, and
> consequently it can make use of comma atoms as a shortcut, just like
> in your example:
>
> > #X floatatom 26 77 5 0 0 0 - - -, f 5;
>
> That's really the same as:
>
> #X floatatom 26 77 5 0 0 0;
> #X f 5;
That's really interesting. That's exactly how I "worked-around" the
issue a few years ago and today I was thinking: 'What the hell am I
doing here? That looks broken'. Indeed, the effect of both examples is
the same. So, if those are equivalent, then I don't actually need
commas and the issue I am trying to address is moot.
> (And you're right that it causes troubles when trying to parse Pd
> patch files within Pd.)
Pd seems to parse:
#X floatatom 26 77 5 0 0 0;
#X f 5;
just fine.
> When comma atoms are used inside a patch (e.g. in message boxes,
> [text define], etc.), they have to be escaped in the Pd patch file:
No, when editing patch files, I don't want escaped commas. I'd like to
preserve their meaning. Adding esacped commas is easy (or at least, I
think so), whereas adding un-escaped commas are impossible (but not
strictly necessary, as you can get the same meaning by other means).
> #X msg 39 327 vis 0 \, vis 1;
> (In [text] it appears as a symbol atom, so it can be set and
> retrieved with [text set] and [text get].)
>
> Here's a combination of these two layers of meaning:
>
> #X msg 49 252 foo 1 2 3 \, 5 6 7, f 20;
> The first (escaped) comma belongs to the message box, but the second
> one will just send the following message to #X (= the current
> object).
My initial question was about how to do the second case: Creating a
message that _ends_ with a comma. Not: Creating a message that
_contains_ a comma.
The former is achieved with:
[list sechs \, sieben(
|
[text set]
Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20220328/6e2bd845/attachment-0001.sig>
More information about the Pd-list
mailing list