That’s great. Been wanting to try that to see if I get on with it to potentially get it in hardware too. I certainly wouldn’t have got my Noise Plethora without a chance to play with it.
Any chance of asking Befaco if they would consider pumping out a cheap module that provides, say 4 to 6 voltage offset knobs? I find cool looking things like that Motion attenuator limited unless I can offset the voltage. I don’t know why offset modules tend to be expensive and generally only offer a couple of offsets per module.
Would need to be -ve and +ve too. Some modules like ALM Pamela’s Pro offer really cool modulation, but all +ve voltage, it’s really annoying!
I’d seen that sebsongs one, but only seen mention of it as a kit. The Sinc Pravus does look perfect though, 4hp is ideal. Just wish a utility like that was a bit cheaper, £140 seems over the top to me for what must be relatively simple components.
I just installed the August 1st arm64 beta from your github, and found it installed a plugin-arm64.dylib. Had to delete old plugin.dylib and rename the arm64 one to plugin.dylib to get it to work. Looks like it was not built against the Rack SDK 2.4.1, which did fix this afaik…
Hey thanks for doing this. I’ve been really wanting to use Noise Plethora as a staple and was wondering if there’s a way to get external control of the Program/Bank knob? I’m not sure if it’s like that for any param that’s ‘Infinite’ in the code; just glancing at it. Besides the standard midi mapping I’ve tried the stoermelder µMAP but to no avail. I was hoping to have a complete interface in TouchOsc for Noise Plethora but it’s the only thing that can’t be mapped! Is it something that could be changed in the code if nothing else?
Right, well in a way it seems exposed as it is recognized by a mapper. It’s just that it still doesn’t respond. I have a feeling it might have to do with it being a +Infinite,-Infinite control but I’m not sure.
Guess I’ll just have to experiment when I have some time and if I have any success I’ll post it for future reference
Yeah you can change which element within a bank is selected with CV, but missing is the ability to change bank (apart from this, I’m not sure why you need control of that knob)?
Apart from that I can use touchosc on an ipad as a control surface to control all of Noise Plethora with my fingers. Same thing if I had my midi controllers. I like to use my hands, not the cursor.
Sorry, OT, but scrolling back up (!) I mentioned that £10 stand with the 7U case (which I built a few weeks ago). I am using it with a pair of those stands. It’s rock-solid. It was OK with just the one, but I wanted to be on the safe side, so I bought a second one. A bit cheaper than that $150 stand that Make Noise sell for their case
The case does actually have holes for a Vesa mount if one was so inclined.
I’ve been working on various new things with Befaco. One of these is MidiThing Bridge device, that lets you send 12 channels of CV to the hardware device. Some more details of how this works is here.
This works well on my Mac computer, and well on Befaco team’s PC, but @Omri_Cohen has been testing and is running into high CPU spikes (when lots of channels are patched up). I’m not especially familiar with Rack MIDI, the implementation I’ve used is very similar to that of VCV CV->MIDI module. (Essentially under the hood, it sends 12 channels of pitchbend messages, which are used to encode CV via 14 bits).
My question to smart/midi fluent people, can you see anything I’m doing obviously wrong here? People can technically test this on their machine, as @Omri_Cohen could re-reproduce selecting an arbitrary MIDI device (i.e. you don’t need MidiThing hardware to reproduce seemingly). I can’t reproduce on my mac setup.
First thing I’d try is to omit setting the message frame. I suspect this could trigger re-sorting of the outgoing message queue, which could significantly impact performance. Let Rack handle the message scheduling.
Your algorithm for rate limiting is bursty - you wait for the trigger then send messages for all the active channels in one pass. it might work better to distribute the channels over time in round-robin fashion.
I’m not a programmer, but I’m curious. Would it be relevant to have a midi port speed selector - the connection from VCV to MidiThing2 is most likely going to be USB / atleast 12 Mbps - maybe the "MIDI baud rate is 31250 b/s . . " should be changed in case of faster midi connections ?
The MIDI 1.0 standard specifies the rate, at least for DIN connections.
If you look up the physical MIDIThing, it has a DIN plug on the front (not USB).
MIDI 2.x doesn’t limit the transmission rate, but then Rack’s MIDI layer doesn’t support 2.0.
But you’re right - depending on what device you’re sending midi to, it might be good to be able to adjust the rate. But then, if you’re sending too fast, most devices will just drop messages.
As far as performance, it might be useful to avoid sending messages when the value of that item hasn’t changed.
Thanks for the input, very helpful! A few responses:
This seems to have a negative effect, the signal from the MidiThing suggests things are getting dropped somewhere along the way. Results below (note that MIDI thing applies some light filtering on the outputs to denoise hence the odd rounded stepped look):
I am connecting via USB, but I find that if I increase the rate I get odd behaviour, as in it seems to queue up message faster than process them on the hardware, and so it plays them with a lag that can last for quite a while. Not sure if this is a Rack thing or a MidiThing issue, but looks like better-than-3125 B/s isn’t possible currently.
I think this is a good idea, and I’ve implemented it. But it also made me realise that if you want to do this right the effective refresh rate depends on number of active channels. So 1 channel you can run at 3125 B/s / 3 bytes = 1041 Hz. But if you run all 12 channels you can only update each every ~87 Hz which actually is pretty restrictive (maybe alright for gates/pitch, but not for envelopes etc).
I guess this is just a fundmental limitation, which is a bit sad as it restricts the usefulness of the module. Unless I’m missing something? Given MIDI over USB might be the normal use case, can I exploit this / am I doing something stupid to not be able to use extra baud rates?
Finally, @Omri_Cohen - does this fix the CPU spikes issue for you at least?
Just curious if the MCU on the MidiThing2 does any rate limiting to the usb midi - it has TS midi input too - it may be limited to old 31.25 k that was max for 5pin DIN / TS.
I don’t think it’s known by us mere mortals what MCU it uses - if it’s Teensy4.0/teensyduino - and I don’t think we can see the source yet.
I hope it will use the full benefits - and deliver “data at rate hundreds of times faster than the original MIDI 1.0 hardware specification .” usb.org quote
Is it something that could be changed in the code if nothing else?
