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ā.
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.
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:
I remember being super amped to get a 1200 baud modem for my Atari 800 in college.
