Yes, my thoughts exactly. Also, it would be a shame if the new controls could not be applied to Frolic. That is why I suggested an additional expander. The Tricorder X,Y,Z values would come from either Frolic or Tin. All the other display controls would come from a new expander.
Would this be an expander on the right side of Tricorder?
It could be. You can also chain expanders, though that is perhaps a bit more complicated. I have successfully developed chainable expanders for my Venom plugin. I do not mess with the messaging. Rather I let the master module do all the work, reading and writing directly from/to the expander ports and parameters. I can only assume that is less complicated. For me the big advantage is there are no sample delays introduced.
Hi Don, I really like the tricorder very much,
and I would like to have one feature added,
I would like to have CV controll over the rotation speed.
Would this be possible?
Copper CV inputs are HSLA. Several modules in pachde-1 exchange color using the rack extender mechanism, but not via rack message passing.
I was looking for some such standard for exchanging nvgColor on a single cable, but there isnāt anything that existed at the time.
There was lively discussion of data wire protocols in general, for color. text, and other stuff that resulted in a collaboration that created the Tipsy encoder and protocol. Now use for text in Basically.
I havenāt gotten around to implementing that protocol in Copper for color exchange.
Iām open to reviving a collaboration on color exchange. Tipsy could be used with a mime type for Rack hex format (#RRGGBBAA) as text, which is also the clipboard format used by Copper and a number of modules in their menus, with the basic Rack text menu control.
The core insight in tipsy was a float is a sign bit, a few exponent bits, and 23 mantissa bits
RGB is 24 bits so you could fit it exactly in a constant exponent signed float using basically the same trick we did.
1 Like
An nvgColor, the native Rack color format, is 4 floats of RGBA, values in the range 0-1, and thatās what I am most interested in exchanging. Of course, youāre generally specifying these using the functions/macros that convert 8-bit components to floats. But, with CV control, you can get more subtle and smooth effects working with the float values.
The color format used in nanoVG (Rack SVG code) is 8-bit BGRA packed into a 32-bit int, but these are just internal to the SVG handling and not very useful for most Rack code.
8-bit RGB packed into a float is ok in a lofi 90ās Windows95/Nintendo kind of way ;-). Opaque colors only, no transparency.
sounds like a poly 4 cable would work just fine if you want the full resolution as opposed to just 24 bit RGB.
1 Like
yep ā that would work, with no packing required.
The currently released Copper sends HSLARGB (scaled to 0-10v) on its polyphonic output jack, so itās ready to go.
Now that you mention it, I should have arranged them as RGBAHSL, so that itās compatible with anything that sends just RGB or RGBA. Iāve opened an issue to add this as a right click menu option for the next release.
3 Likes
