PD : question - space character

Organelle Patching
1

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.

context,
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!

2

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

pp

3

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.

4

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

1 Like
5

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
6

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

7

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.

8

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).

2 Likes
9

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.)