Header may contain metadata, separated into chucks by RS. Each record begins with a 4-byte record type id (similar to TIFF AIFF, etc). followed by data up to next RS or STX. Text begins after STX, null-terminated, followed by ETX. Header may be empty (NULL NULL SOH STX <text> ETX).
We have all the markers we need in the ASCII portion of UTF-8. Perhaps a float value unlikely to occur in audio/CV and not a valid message block value is a good way to fence the text messages. And that ETB seems not necessary.
I think packing no more than 2 bytes in a float is convenient. No need to spread bits around – just 16 bits in the fraction. Just 1 byte per float simplifies some things, but writing the code will tell if packing more creates issues. If 2 bytes, then messages will have to be padded if they’re an odd length (zero-padding makes sense to me).
yeah agree with all of that. the only reason i thought about 3 bits was (1) we had room and (2) it is 50% more bandwidth for when someone inevitably makes an insane video codec with this
To your header I would add some version information so like SOH VERSION # TYPE<mine> so we can migrate a protocol and replace text with binary but otherwise agree completely
despite my strong desire i’m not going to write an encoder/decoder this weekend but would happily review, use, comment, collaborate if you want to. Or if you aren’t going to I might do it later in the week.
what a nifty idea.
oh and I guess we should make sure the idea still works for @StochasticTelegraph
oh and if we do it the first module to write is a ‘text scope’ of course.
As soon as there’s a module that sends text, I’ll add it to my Info module.
I just opened the issue to submit my plugin to the library.
It might be a variant of Info or an extender geared for dynamic text display.
I imagine a full height scrolling text billboard with options for however many parallel lines you want scrolling across. For the retro roadside light sign look, I know of some fonts to make that look right.
yeah just someone has to write an encoder and decoder library
I guess “first one of us to start typing something in say something on this thread so we don’t dup work”! And if none of us ever type anything then it won’t happen.
I’m a little busy with the last steps of publishing my first plugin, but as soon as that’s done (and I finish splitting the logs my wife asked for), I’ll set up a new repo and scaffold a couple of modules that we can use as a vehicle for working this out. I’ll follow up here when that’s done. probably 3-4 days.
@pachde My concern was less about protecting users and more about reducing their confusion. I guess we’ll see how that goes.
This is a far, far better result than I expected when I started this thread!
I can get started on writing a “console” module (current name, “TTY”) and on adding text creation to BASICally. That should be sufficient to test out the encoder/decoder once someone starts writing it, yes?
Actually made some pretty good progress today. Might have something to show tomorrow. If you are interested in reading half finished GitHub pushes, PM me.
As a bit of update, here’s the current state of the unreleased TTY module I’m working on:
NB: UI is quite preliminary! I didn’t bother to add any narration to the video, but here’s what’s going on:
Scene 1 (0:00 - 1:06): TTY displaying a series of values. Note that it only displays values that differ from the previous one.
Scene 2 (1:08 - 1:38): BASICally sending text to TTY via Tipsy. My current suggestion for marking an input port as expecting Tipsy is the oversized “+” behind it.
Scene 3 (1:40 - 2:13): TTY showing the actual sequence of values behind Tipsy, and also demonstrating using BASICally to send a text message that clears the TTY screen.
Scene 4 (2:14 - 2:30): A silly take on Oblique Strategies, where BASICally suggests things for the viewer to do while playing a patch.
Scene 5 (2:34 - 3:28): Demonstrating copying from TTY.
Anyway, I thought I’d share where it’s heading and see if people had useful suggestions that I hadn’t thought of or let me know of functionality that would matter to them… There’s still a lot to do before releasing, but for certain I will:
add more value and text ports, so that the user doesn’t have to deal with merging different data streams into one (especially tricky with Tipsy).
add string variables to BASICally. And then likely some string operators.
Having something that created an audit trail of what you did during a jam would be pretty cool. Especially if it could be smart enough to precis usage e.g. didn’t show reams of cc values.
Huh! So some compact representation of a long series of CV values, which is:
recordable
editable (by typing)
replayable
??
Like a series of:
timestamp: value
timestamp: value
timestamp: value
...
With the timestamps increasing.
This verges a bit into territory usually handled by a DAW…but it doesn’t have to be…so, interesting! And a promising use case for a module that takes text as an input.
Admittedly, “recordable” and “replayable” could be handled by a long “tape” recording, but this could be a far more compact representation many varieties of CV, and adding “editable”.
I wasn’t personally thinking of ‘replayable’, more as an aide-memoire to tell you which modules you used in the jam (and when). As you said, linking to a DAW would make more sense if you wanted to record literally everything.
Ah, so something that (somehow) knows about all of the controls in the patch and notes when they change. I currently have zero clue how (or if) one could do that, but it is a fascinating thought…
A result of the discussion above is now finally available!
A new text display module, TTY, is now live. Docs are here. It accepts Tipsy text messages (and also can log normal float values from a cable).
BASICally now has the ability to output Tipsy text messages. This allows, among other things, one to log messages from a BASICally program. But there’s an interesting variety of uses.
You can see two minute walkthrough video of example uses for TTY here.
This patch of TTY sample uses is here.
I’m hopeful that more modules will start to support the input and output of Tipsy text messages, as I think text is a potentially powerful tool for manipulating a patch and getting human-readable feedback from a patch or module.
Thanks again to @baconpaul and @pachde for encouraging and materially contributing to this idea.
Please excuse my intrusion in this discussion (absolutely brilliant) but when I read this line I had a good laugh. Ditto for me and yes… I was literally mesmerized by the sound of modem connecting. First there were BBSs, then Win3.1 with socket… In a way I miss those sounds. My first modem was a 300 Bd on my Commodore 64, my first digital and digital music love!
