@steve describes the extender protocol, which only works between cooperating immediately adjacent modules, which limits you to 2 connections, unless you build some kind of transitivity between these cooperating modules (which some plugins do), and even then you’re limited to adjacency.
Other modules mentioned in the thread are more general, like teleport and traverse cables to find the modules to connect, removing the requirement for adjacency.
These mechanisms work great but are limited to exchanging floats (inputs, outputs, params), or dedicated private message types.
What’s nice about OSC is that it extends to a variety of relatively self-describing data types, and also supports a rich addressing mechanism so that you can choose point-to-point or broadcast based on pattern matching, with precise timing to boot. I’ve also described a way that a broker module could receive OSC and translate it so that you can also do inputs, outputs, and parameters to any Rack module.
I’m not talking about the expander protocol. The message bus is something different.
EQMaster can pull track names from MixMaster regardless of where the modules are in the patch - they certainly do not need to be adjacent (and EQMaster is not an expander of MM, it is a totally separate module).
Yeah so last week I made it so surge can auto connect to mixmaster and to other surges (and soon airwindows) more easily. You can just write code to examine all the modules and then inspect their pointers with dynamic cast. Works well!
That leads you to a solution like
Make a small library with a marker and function interface like SupportsText_v1 and don’t get it wrong since once it’s in the wild you can’t change it
Your text source module checks if the far end of a cable or another point in the patch or an expander neighbor - any will give you a module *
If that module is dynamic Cast non null to the interface then bobs your uncle
I really think this is the most correct way to approach the problem even though I vastly prefer the obviously inferior and silly audio encoding of modem and teletype streams onto audio cables mostly on aesthetic grounds
Do you have a link to this message bus API? I searched the Rack API reference and I’m not finding anything.
I’m guessing that these modules use the technique of searching loaded modules for specific module classes that implement their non-Rack protocol. i.e. use dynamic_cast to find modules implementing an interface or marker type. I imagine that OSC based messaging would probably use this pattern to discover the modules implementing the protocol.
I found this post Marc made in Jan 21 where he links to the message bus code. He didn’t originate this code, another developer did, but I forget who now. It may not be a published part of the Rack API, more a clever ‘hack’ of it perhaps?.. again I don’t remember and didn’t really understand it back then anyway
EDIT: Of course Marc credited the original developer:
//This code is an adaptation by Marc Boulé of Jerry Sievert’s MessageBus
@baconpaul Thanks! (laugh!) Same thought: you describe it much better.
There are some modules for doing OSC, but harder to find because it’s not one of the “blessed” module tags, and when searching you get every oscillator.
But what I’m thinking is something perhaps slightly more general than these OSC/CV bridges in that it provides for expanded range of data types that can be exchanged between modules internally. These private message types used in the MindMeld message bus are relatively easily encoded into OSC.
@pachde The protocol will be very lightweight, despite the abundant creativity of the ideas that surfaced here. A bit more than simply one-character-per-sample as you suggest (there are circumstances where a module’s process() function is not called every sample), but not much more.
Also, I don’t know why any other module would want to decode text; I don’t imagine other module’s wanting to be controlled via a stream of text. I was asking if anyone who writes modules want to send text to a module (which I’ll be writing) that displays it. I know I do (it’s useful for my BASICally module), and I was asking if others did.
Yes, of course, there would be an OSS library for sending and receiving messages.
Primary: allow BASICally to send text to an in-patch console that user can read and copy.
Secondary: open this ability to other modules that wish to do so.
Tertiary: do the above in a way that might open new creative avenue within a patch. I’ll need to try it to see if there’s really anything here.
Researching this was interesting. I had no idea that teletypes (my first childhood interface to computers in the early 1970’s) predate digital computers by many decades, and that the interface to them was a single pair of wires. And thus how purely mechanical they were. The droning, chattering sound of them is the scent of baking madeleines for me.
One of the modules in the plugin I’m working on would be interesting for receiving (decoding) text.
Such a protocol opens the possibility for someone to invest in a great text editing module, then other modules wouldn’t need to implement their own. The VCV text widget is limited and has a number of issues.
I want something better for my Info module, but I haven’t prioritized the time for that effort. If you have a good text editor that can output the text, I’d be happy for my info module to receive it.
@pachde@baconpaul Interesting! Surprising! Allow me to probe that notion a bit more.
Do you want a text editor (human edits a block of text) or a command line (human submits text line by line)?
1.1 Text Editor: Do you want the editor to live inside your module or outside of it?
1.1.1 Inside: I’ll humbly suggest you look at the editor embedded in my Fermata module. I wouldn’t say it’s encapsulated as cleanly as possible, but it is already shared between two of my modules. I’m happy to take suggestions on how to make that something you could use within your own module(s).
1.1.2 Outside: Interesting! Why is that a superior experience for your users? How would you envision the interaction between your module Foo and the editor module Bar to work over time?
1.2 Command Line: Interesting! Do you want the command line to live inside your module or outside of it?
1.2.1 Inside: Has this proven hard to do within your module? I haven’t tried it, so I wouldn’t know.
1.2.2 Outside: Interesting! Why is that a superior experience for your users?
I’m being brief here, so the questions above may look snarky, but I’m genuinely curious about your thinking, and wondering if the TTY module I’m conceptualizing should have an output port as well.
Let’s take a case adjacent to mine, imagine you have a sequencer which can play a bit of music in abc notation, so clearly you can just type in the notation
But if you could externalize the text for the currently playing segment you would separate the problem of parse play etc the text from the problem of pick the text to play,
So imagine a simple case, module one has a port which takes abc notation text and a trigger, in trigger the current abc sequence heads out per the clock as v oct
A second module has 15 phrases in it and selects one at random to send down
But once you do that you can write modules which generate notation strings and send them to the sequencer, which has now really become a sequence phrase interpreter,
To do this you need to send text along a cable,
I have other worse ideas too, some of them based on squinky and me on discord chatting about making the Sam lib a bit more modular, a project I mostly have done,
But basically if you start thinking about notation as content and text as notation whether it is abc or lilypond fragments or other formats, you get a need to move text around
My description of these awesome sounding modules does not imply that either the ideas are fully baked or that I will ship them ever, chuckle,
Another case I have is a chordal sequencer. So you enter notation like c7b9 g7 d- a-7 as your sequence with each chord in a cell and then you basically have a jazz lead sheet sequencer, would be cool if you could send sequence strings from external tools for same reason. Like stead of that being a lead sheet module it s really a “comp a single chord with reasonable state management for voice leading” and then you send a stream of chords on a cable.
It’s a clipboard format, so it goes through the clipboard rather than a cable, so entirely user-ui-driven. This is fine for copy/paste data interchange, but there are good scenarios for automated and connection-oriented (point-to-point) channels. Automated pushing to the clipboard is not a good user experience.
As for my immediate use case, I have a simple text display module, ready to receive text. It is extended another of my modules (a color picker with modulation) that enables animating the color of the panel and the text. Clipboard would serve it fine for its current main patch notes usage. I can imagine expanding it so that it could be like one of those electronic billboards that can flash and scroll text, or accept simple formatted text. I imagine text sources could send text on a trigger for display. Other modules can interpret each bit of text as they will.
JSON is text (a UTF-8 blob in this case), as is YAML, Javascript, HTML, Markdown, laTex, CSound, Supercollider, LUA, lilypond, etc. Up to the receiver to interpret it (like OSC – the standard specifies no semantics for the data). Best to allow for UTF-8 (8-bit code units): no good reason to use any other encoding.
A future set of modules I’m slowly working out (think generic midi pad like a monome) are configured using a text-based notation. Since you only need to edit while you’re setting it up, it would be nice to plug in a text editing module for that data entry, then remove it when done (or leave it for convenience).
As you outlined, there are use cases for line-at-a-time (sending triggered by hitting enter at the end of a line) and for multiline text sent by a manual (button Ctrl+Enter, etc.) or CV trigger.
No down the cable, it was just for clipboard. I just meant to point out that there is no need to invent a new encoding of notes, as there already is one that a few ppl support. Wire part, no, that’s different, and I got nothing there.
See other reply.yes , I was thinking of any typical layered protocol. The meaning of the enclosed data doesn’t need to depend on the way it’s moved. Like how tcp can be on top of Ethernet, or on top of something else.
I was thinking if the musical encodings like abc and lily pond as my encodings, and the standard jazz chord names from iReal pro. But definitely curious what’s out there already of course!
