I deemed that level of DC ok. It’s like 30 db down. It’s like 0db Down in every other min blep VCO I looked at. Also, crank the frequency up really high to see a ton of DC…
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!
Sure! Technically Morphader can work as 4 offsets at 0-10V. Or do you mean some like a quad version of dual attenuator?
These might suit though:
1 Like
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…
1 Like
Good catch, I’ve bumped the SDK version for the dev builds on github.
2 Likes
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?
If you can change the code, you can expose anything you like to CV/Parameter control.
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)?
1 Like
So I don’t have to rely on the cursor.
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.
1 Like
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.
1 Like
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.
Main relevant code section is linked below:
CPU spikes on Omri’s machine:
1 Like
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.
1 Like
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.
Midithing 2 has USB though.
1 Like
Good one!
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?