PD : question - space character

so I want to have a ‘message’ that contains a string which can contains (consecutive) spaces

I know that PD, treats ‘strings’ as a sequence of symbols.
so in the simple case, you can reinsert a space for every symbol
e.g. “a.lazy.fox” = [a] [lazy] [fox] , convert back , put a space after each.

( . = space, to get around discourse formatting issues :wink: )

but that doesn’t work if I was to allow consecutive spaces…
“a lazy…fox” , still is [a] [lazy] [fox], so translated back I only have one space

I know I could implement substitute the character, but thats a pain, since it means that character becomes unavailable for use.

basically, Im writing parameters to the screen and want to right justify the numbers e.g.

|mix               50.7%|
|depth              3.0%|

so I pad the text with spaces to achieve the justification.

@oweno this ties into setScreenLine , basically, I want to send the entire LCD line in one go from PD.
I might be able to get around this (ive got a complex solution involving null symbols) , but perhaps for other users… if might be better to have an escape character thats understood by mother host.
e.g. ^s = space ^^ = ^
this way in PD its easy, you can just write “a^slazy^s^s^sfox” and you know you will get the correct spacing.

am i missing something, does PD have a better way to work with ‘strings’ that it wont break into symbols!

maybe an external. maybe look @ moocow stuff? i will look when i get home


actually I’m sending this data already form my own external… the issue is, Im sending the screen lines out by sending to screenLine1 , which then gets manipulated via PD… and has to be processes by packOSC.
(so that means packOSC needs to know how to translate the messages)

I actually had solved the issue using null symbols, but ive tripped over a bug in the OSC handling in mother host, basically

oscsend localhost 4001 /oled/line/1 sss "mix" "" "10.2"

here I’m using a null symbol to generate a space, and it works EXCEPT bizarrely when the first symbol is 3 characters, at which point the osc parser, gets confused by the empty string, and scrambles the subsequent symbols, so gets displayed at mix 0.2 !!!

if its 2 4, 5,6 it works, just not 3… also if the next character is not a null it works too.
so this work fine

oscsend localhost 4001 /oled/line/1 sssssss "depth" "" "" "" "" "" "" "5.2"

so im a bit caught up, I can work around it in PD, but then setScreenLine in mother host trips me up…

anyway, Im starting to think this is not the correct approach… I think I’ll actually just connect my external directly to the mother host osc port, and bypass PD/mother.pd altogether… this will allow me direct access to the new graphics primates too :wink:

anyway, good news is the new formatting does look really nice… so once over this hiccup I’m going to be pretty happy with it.

it sounds like you have it dealt with --it was something like string2any or some such anyhoo

1 Like

also you have to calculate the number of spaces to right justify that last value right? is this a pain? there could just be a separate OSC message altogether that just right justified the last element… but yeah the strings are a pain especially with packOSC

hmm, I remember a bug I ran across in the CNMAT OSC library (used by mother exec) that was causing problems decoding strings of certain lengths… might be related, or not fixed correctly

1 Like

yeah, that bug looks suspiciously like the one I’m seeing :slight_smile:

I’ve not had a good look at it but the last character in the characters array for 5x8 in fonts.h looks like the space character (0x0,0x0,0x0,0x0,0x0). Maybe that would work for a hack for your “a^slazy^s^s^sfox” idea.

Also could try the new graphics messages:

/oled/gPrintln 0 10 8 1 mix
/oled/gPrintln 104 10 8 1 3.0%

The params are x, y, text size, color (0 or 1), stuff to print. So the first one prints left side (x=0), and second one prints on right (x=104, but still need to calculate x depending on num of characters, 4 characters at 6px each in this case).


Yup, thats what I meant about using new graphics primatives - it’s probably the best approach.
Though now I’ve got around it by sending osc directly to mother host, so don’t need to go via PD messages , this will also be a bit more efficient CPU wise too.
( I can combine the approach though, so use new graphics messages over a direct osc connection.)