In this comment, @FiroLFO suggested adding an optional text window to BASICally to allow BASICally programs to write text to it. I can see this is as being useful for:
- writing out values for debugging a BASICally program
- for materializing a sequence of values that you like the sound of and want to preserve or use elsewhere
- creating Oblique Strategies-style realtime instructions while creating or performing a patch.
To name a few ideas I had this morning.
My first impulse is to add this as a integral part of BASICally, but before I do that, I want to make sure I’m not missing an opportunity to make something more generally useful. Here’s that idea:
- A protocol (let’s hand-wave away the numerous details for now) that allows text to be codified into values that can be passed over a VCV Rack cable.
- A module with a text display window and a single input port. As signals are received via the input port, they are interpreted through the protocol in (1) and displayed as text events that are shown on the text display window.
I’m currently imagining the manner of display to be similar to a scrolling console such as a command shell/Bash shell/whatever you think of it as. Probably with a “clear” command and maybe some font/size control? Again, TBD.
So, module developers, is this something your thinking would be useful? To be clear, I don’t mean for for your development so much (we’ve got log.txt for that), but for displaying optional text to users. Perhaps it’s describing (again, in text) the internal state of mind of your module in a way that lights cannot? Or for displaying optional error messages or hints based on the current state of the module.
Oh, and seriously goofball things one could do with this include running a text signal through delay, tape loops, reverb, etc. and displaying the result. Not to mention the ancient joy of “listening to the modem”.
Could use text to drive a sequencer, i.e., “perform” a sentence
So I have two thoughts
The more obvious one is make a tag interface for the far end module and check if a param is connected with a cable to a module and send data to the end of the cable using a c++ blah blah with the module pointer on the far end of the cable dynamic cast etc and you know the drill and that’s boring
Then another part of me thought if you are serious then you should write a library which encodes data using the audio protocol from 56k modems and sends it down the cable as audio signal. You could then hook it up to audio out and hear the modem squeal. I don’t know if you are of the age where you heard this at outset of internetting. But it really does seem like the rack way. Write an mit library which goes text → modem squeal and vice versa and hook up the handsets between your modules.
Neither of these are code and neither are that useful. But if you do the second one it would be kinda epic
@baconpaul ,I’m of the age when we used ASR33 teletypes running at 110 baud. I remember being super amped to get a 1200 baud modem for my Atari 800 in college.
I would have thought that a 56k modem would be too fast for lower VCV sample rates, but it turns out that a 56k modem works at 8000 samples/second. (Maybe, I didn’t read the article that carefully). So perhaps what you suggest is doable? While I’m not prone to retrocomputing, I don’t disagree that such a thing would be epic.
Either way, I have no intention of doing this the “boring” way you alluded to. Like I said above, modular manipulation of text signals would be enjoyably stupid/clever/novel.
I actually wonder if the 56k protocol is too robust and good at rejecting noise to withstand manipulation; now that I think of it, I kind of want a protocol that still tries to emit text when manipulated by other modules, that presses on when noise has been added. I don’t want error correction, I want error enhancement! The ASR33 protocol is a gesture in the direction I’d like to lean in (except less binary).
You know, I posted this hoping you all would talk me out of this idea. That did not happen.
I wouldn’t expect much uptake for decoding text if it’s CPU intensive, complex to implement, or difficult to bring the dependency in (you would plan to publish encoding/decoding as a usable OSS library, wouldn’t you?).
An alternative is to encode the text in MIDI, which does have the means to embed text data in the midi stream. SysEx, is one example. The Haken Eagan Matrix sends text and binary data using cc’s in its own protocol that in some ways is easier to deal with than SysEx (it’s friendly to running status for one). I don’t understand yet the routing of MIDI in Rack, so not sure how flexible that would be for connecting modules. MIDI 2.0 has even more opportunities for useful data interchange.
I’ve had thoughts in a similar vein on how to have interchange of non-CV data between modules. In my case it was transmitting colors (including transparency – opaque colors are easily packed into a float without colliding with NANs and other things that are bad in a floating-point stream). Something that doesn’t involve audio codecs would likely be easier on the CPU.
I wish Rack had data cables with a multi-format protocol (consider MIME in mail and HTTP). I imagined the ports for these would look like USB ports, with corresponding distinct look to the cables.
I was thinking more along the lines of using the text characters themselves as control symbols and somehow (insert clever technique here) mapping the characters in a text sequence to control values. For example, one approach might be to map the characters to their Braille representation which gives 6 (or 8) binary ‘dots’ per character. A receiving module could interpret the on/off state of each dot as CV high/low and react in some way (insert clever reaction here).
Perhaps something like a quantizer that selects notes within a given scale based on the ‘on’ dots in a received character. Character transmission could be polyphonic with 6 (or 8) channels where each channel represents one of the dots. Another spitball would be a step sequencer of 6 (or 8) steps that cycles through the steps that are enabled by the most recent character received.
You can always just cast the byte of each character of the string to a float, scaling it to 0-10, sending one byte per sample. End with a 0 value. Viola, UTF-8 text on the wire. If you want formatting, send RTF or HTML, both marked-up plain text. It’s certainly possible to pack more text bytes into a float, but adds complexity. Just sending scaled bytes is dead simple and likely efficient enough for most purposes.
This would serve to send text but wouldn’t be robust to signal processing and get text back out.
I have also slammed a handset into a coupler to get a 300 baud connection. Good times.
So yeah 56k/v90 is complicated but indeed there are loads of other protocols like teletypes and stuff. And I love the idea of being semi robust under audio path manipulation. Another one to look at is how old home pc streamed to tape but I think that is the same protocol as early modems
I guess is your project “send text from basically to a console” or is it “make a small library which encodes text as audio and decodes it and ask everyone to do weird nonsense with it”
The second sounds way more fun to me but I’m not writing it! Like send text to a speech synthesizer fun. If that small library was a nice separate bit of mit c++ code I would probably do something stupid with it this summer too.
I may be particularly lame, but the Voytra-8 most certainly did not use any modem protocol, at least intentionally. I think it was basically two arbitrary tones one for 1, one for 0. all generated and recovered on software on a CPU that had no multiply instruction.
btw, there are already VCV modules sending MIDI over audio, which is pretty similar. Like this one: VCV Library - Ahornberg MIDI over Audio.
I’m sure there are a bunch…
My first tape drive was a trs 80 model 2 and it seems the internet has cracked that format with an mit licensed library already: https://github.com/lkesteloot/trs80/tree/master/packages/trs80-cassette
Caps out at 1500 baud tho
Why not use a canvas, control a turtle pen to ‘write’ a character on it via CV then run OCR on the resulting character? Seems about as worthwhile.
Oooh have you written a module which allows cv to turtle graphics? Can you point me at it?
Haha first I put the text string through a slew Limiter.
Why not use the expander API?
Or use the mechanism behind Little Utils Teleport?
But technically, text doesn’t need to be transported at audio rate, the GUI frame rate is far enough (in contrast to my MIDI Over Audio module, where latency and jitter have to be addressed at audio rate).
Further more, you have to decide what encoding you want to use:
- 7 bit ASCII
- 8 bit ASCII
After reading Naomi Klein I would advise against it
VCV Scope in X-Y mode?
Waiddaminnit - I guess you need a persistent trace.
Huh… It’s getting very sophisticated!