Perhaps even a rabbit hole searching for a rabbit
2 Likes
Yeah this is one way to get the far module reference by adjacency like my very first suggestion and is absolutely the way to do it if you want it to be non-silly. Expander api or traverse outbound cables to find connected endpoints then use an api with pointer references and stuff.
2 Likes
Yeah you need a sort of scope with four inputs which are x y penupdown and clear. And then you could write a logo to cv interpreter as a separate module.
I am glad I have lots of work to do on surge and shortcircuit otherwise I might actually code up some of the truly terrible ideas ive mentioned in this thread. Lol.
1 Like
And (damnit) if you made all four of these polyphonic with a different color per trace you could do a laser light show style visualization with cv. I really kinda want to write that now. Chuckle.
2 Likes
perhaps OSC would be a good protocol for inter module comms in rack ?
https://opensoundcontrol.stanford.edu/spec-1_0.html
I donāt know if āportsā and cables are needed, VCV Rack allready uses several invisible connections for parameter mapping, expanders, monome virtual grids, teleport etc.
OSC would be a fine way to encode data. (BTW OSC specs take care to specify that it is an encoding, and not a protocol, because it doesnāt define any semantics for the data).
For use as an interconnect between modules, there are a few things that would be good to have:
- Agreed format for addressing modules in Rack: perhaps something like
/Rack/<module-slug>/<moduleid>(module id alone is sufficient, but including the slug is more informative). - Common open source library for parsing and creating OSC messages.
Not sure if there needs to be a central broker module, or if it would work if each module was a server and a client, with a common library.
It would be straightforward to have conventional mapping for addressing any moduleās I/O ports and parameters: Rack/<slug>/<id>/(input | output | param)/(<port-name> | <index>). This could allow for connecting to an arbitrary module, including those without any explicit OSC support. Now itās starting to look interesting!
Once Iāve finished my plugin and have it published to the library, this is probably something I could get behind and help develop.
1 Like
Excuse my mix-up of terms, this page says protocol. Iām not a programmer.
Introduction
Open Sound Control (OSC) is an open, transport-independent, message-based protocol developed for communication among computers, sound synthesizers, and other multimedia devices.
(my emphasis).
I havenāt read the whole thread so perhaps I missed mention of itā¦ but there is already a āmessage busā that can send text between modules.
We use it in MindMeld to populate the track names on EQMaster from MixMaster for example.
I canāt remember if it uses cables to do it or notā¦
It was a while ago and Iām not sure I even fully understood how it worked back then haha - Marc could probably tell you more.
On the same OSC spec site: Is OSC a Protocol? and OSC is an Encoding.
But this is semantic pedantry, and really only useful for meta level determination of what belongs in the OSC spec ā Iām sorry for bringing it up. I apologize for that.
In any case, a next Rack project I was thinking of working on was a set of MIDI controllers (I have a number of UI sketches), and perhaps extending that to OSC (which has an established way to embed MIDI) is a good direction to go and would fit quite nicely with the ideas in this thread. It would also extend these no-longer-just-MIDI controller ideas to general CV in Rack in a natural way, making them a ton more useful in Rack.
Youāre good, Iām learning, thanks.
@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
2 Likes
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.
Jinx!
1 Like
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
//CharredDesert/src/model/MessageBus.hpp at v1.0 Ā· SVModular/CharredDesert Ā· GitHub
//License CC0 1.0 Universal
//CharredDesert/LICENSE.txt at v1.0 Ā· SVModular/CharredDesert Ā· GitHub
//Downloaded by Marc BoulƩ on sept 4th 2019
3 Likes
@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.
Some quick finds:
- VCV Library - TheModularMind OSCelot (vcvrack.com)
- VCV Library - trowaSoft cvOSCcv (vcvrack.com) (and family)
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.
@baconpaul Goals are:
- 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.
1 Like
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.
Me too! (Not in surge but in my ābadā baconplugs collection)
1 Like