Chinenual Development Thread

auxmux · August 2, 2022, 10:45am

Awesome, great news re expander. Thanks for considering.

aetrion-music · August 2, 2022, 10:09pm

Checked again with the same patch I used before. Timing is rock solid down to the tick when importing in DAW (Logic).

Great work!

Chinenual · August 2, 2022, 11:30pm

Thanks all! I’ll get this submitted to the library forthwith.

aetrion-music · August 4, 2022, 12:14pm

@Chinenual If you are open to a bit more feedback regarding the module design.

Not as a must, but as a potential future update, I would say the panel could be a bit more “explanatory” and easier to navigate on the eye given the amount of inputs in the grid.

Font Size: I know it’s hard to squeeze in all the 10 rows given the fixed height. Having recently received feedback on my own module I can say that we tend to think they’re big enough and readable, but in reality the yellow on black and the small “all caps” letters will be hard for a lot of users to read. Especially if you’re dragging cables all across your patch to hook up midi recorder you’ll be zoomed out quite a bit I can imagine. Though you do have the tooltips that also help with that.
Some form of “grouping” to the inputs (my suggestion would be horizontally) and numbering of the 10 Channels.

This is also something like Vortico does with the fundamental modules like split (also a cool inspiration for a more ‘fancy’ LED Display).

Quick Mockup (trying to stay close to your style so nothing drastic)

Chinenual · August 4, 2022, 12:37pm

Thanks for the feedback! Good ideas and I’ll see about incorporating some of that in the next release.

I’ll also experiment with brightening up the yellow color (at least when used as labels) to improve contrast.

Chinenual · August 7, 2022, 2:54pm

The original release has not yet been added to the Library but I’ve been working in the background on the CC Expander that @Jens.Peter.Nielsen suggested. It also has some UI improvements similar to those suggested by @aetrion-music . It’s ready for testing! (Release Release v2.1.0b1 · chinenual/Chinenual-VCV · GitHub)

MIDIRecorder-ExpanderChain

New expander module for the MIDI Recorder. Adds support for 5 additional CC values per track. Each can be configured with
- custom input voltage ranges,
- the CC control number and
- whether the value should be transmitted as 7-bit (0…127) or 14-bit (0…16384).
- Multiple expander modules can be used - they must be adjacent/touching to each other.
The Recorder has new config options
- 14-bit CC can be sent for MW (CC1 & CC33). Default is 7-bit (CC1 only)
- VEL, AFT, PW and MW voltage input ranges can be changed to match the source modulator outputs. Defaults remain as in the 2.0.0 release (which matches the VCV Core MIDI-CC module behavior).
- Revamped the UI - brighter BPM LED color, more readable labels. Track row labels.

The updated documentation is on the “develop” branch at: Chinenual-VCV/README.md at develop · chinenual/Chinenual-VCV · GitHub

Squinky · August 7, 2022, 6:32pm

Yeah, some ppl use tinny fonts and it makes the panels pretty hard to read. Wen I made modules I always used 14 point text for labels, using the Robato regular font.

auxmux · August 8, 2022, 6:04am

Amazing, thanks for adding the cc recorder expander.

Squinky · August 8, 2022, 7:28pm

How do you allocate memory while recording? Or do you pre allocate first?

Chinenual · August 8, 2022, 7:59pm

MIDI events are allocated as they are recorded. Memory is freed once the resulting file is persisted (after the recording is stopped). Or at least that was the intention - I believe I may have spotted a bug - the memory is freed on module onReset() and when the next recording starts. I’ll fix to also free immediately after persisting the MID file.

Squinky · August 8, 2022, 10:01pm

If you are allocating memory from your process call you will almost certainly create a priority inversion, and the pops and click that are inevitably created by that.

Chinenual · August 8, 2022, 10:21pm

Mmm. I haven’t noticed this yet (and I’m testing on a single threaded relatively low powered laptop). CPU utilization is low, but perhaps memory allocation is lurking as a problem I haven’t noticed yet.

Definitely eager to hear from those that have kicked the tires - anyone seeing bad behavior? @Squinky : any advice for how to stress test this so I can measure something?

Squinky · August 8, 2022, 11:01pm

Yeah, it won’t happen all the time. I remember working at a pro audio company 10 or 15 years ago and we had a stop ship bug where we were getting like one click every 10 hours or so. Traced it to a place where the compiler had added a call to malloc that didn’t run very often.

There is much written on why one should not to this.

My own paper is pretty popular here:

github.com

squinkylabs/Demo/blob/main/docs/efficient-plugins.md

# Efficient Plugins

## The challenge

When most computer software is slow, the user needs to wait longer for the software to respond. But with real time audio systems like VCV Rack, slowness manifests differently. Typically everything is fine until enough things occur to slow down the audio calculations and the buffers underflow. The results are usually a sudden onset of pops, clicks, or missing audio.

When writing plugins for a real-time audio system like VCV Rack (or VST, Audio Unit, etc.) there is the additional complexity that the “system” is a collections of software from different authors with differing strengths and weaknesses.

One plugin that is a CPU hog, or otherwise misbehaves, can make the system click and pop. For the user it is very difficult to tell which plugin is the culprit. For this reasons, it’s very important that any plugins distributed to end users be well-behaved, and that they document any known issues.

## VCV Rack 1.0

Rack 1.0 will be multi-threaded, which means that most users will see a 3X increase in available CPU. That will allow many of today’s inefficient plugins to work without immediately causing pops and clicks. But that doesn’t mean we will be able to get away with inefficient plugin code. VCV users want to use that extra CPU power to make bigger patches that are more reliable. They don’t want us devs to use it ourselves to run our inefficient code.

## What causes buffer underflows

At the hardware level, most audio interfaces operate on buffers of audio data. The audio software does its processing, and delivers a buffer of audio to the interface. If the last buffer is still playing when the new one is delivered underflow will be avoided. If for some reason VCV Rack is not able to deliver a buffer of audio before the previous one has played, an underflow occurs, and the audio interface can’t play anymore.
Buffer size is settable by the user, and typically ranges from 64 samples to 512.
VCV 0.6 has a single-threaded audio engine. If there aren’t a lot of other programs running and competing for cores, that means VCV will have an entire CPU core to run audio processing.
There are three things that plugin software can do that will cause VCV to underflow:

This file has been truncated. show original

But if you just google “audio pop and click malloc” you will get some good hits. This one is very much on point: Four common mistakes in audio development

For me, since I leaned this lesson long ago I have gone to great pains never to do it, so I have never called malloc from the audio thread in a VCV module. I have sometimes gone to great lengths to avoid it. Like when note data needs to be allocated in a my sequencers

There may be ways to demonstrate/test this, but nothing super easy occurs to me.

Chinenual · August 8, 2022, 11:50pm

Thanks @Squinky. That’s enough for me - I’ll find a way to fix this.

Meanwhile, I’m hoping to get feedback on the module as it is. So for those of you planning to help test, please don’t wait. I’d like early feedback on the rest of the new features and UI, even if there’s a theoretical performance problem lurking…

Squinky · August 9, 2022, 12:49am

it’s not a theory, it is a generally accepted fact. But as long is you fix it eventually, that’s great. And for sure not a reason for ppl to avoid testing - there are hundreds of module out there that do the same thing (I’m guessing).

chaircrusher · August 10, 2022, 3:26am

Trying to imagine a way to avoid allocating memory off the audio thread. Keep thinking of ways the concurrency will blow up any simple solution. If you have a thread to keep the allocation outside the audio thread, you have to find a fast way to pass the events to the allocation thread, preferably without having to use locks.

This is serious programming that people smarter than me solve all the time, but don’t know if anyone has solved it for Rack plugins.

Squinky · August 10, 2022, 3:54am

none of my plugins block on the audio thread, and yes, it’s not easy. But I never made a plugin with an allocation pattern like this one, Seems they have a solution that seems sensible. And, yes, lock free programming is not super easy. I think @Vortico is pretty good at it, from what I’ve seen. But most VCV devs are not. It’s a pretty esoteric thing. unless you are just a genius (which I am not).

I would never make a plugin that blocked the audio thread. But that and a zillion other things conspire to make it such that making a “high quality” VCV module takes about 10X more effort than making a bad one. no thanks, I don’t want that job.

Squinky · August 10, 2022, 3:56am

One simple solution - pre allocate 1GB of ram ahead of time. Everyone has a free gig, and you will never need that much. I’ve never done anything that dumb, but it would actually work fine.

Chinenual · August 10, 2022, 2:25pm

I’ve fixed the allocation bug @Squinky highlighted. I adapted the same design that @Vortico uses in the VCV Recorder (a rotating set of buffers with all allocation on a worker thread). There’s a small chance of some thread synchronization overhead if the worker thread can’t keep up with the main audio thread, but I’ve tried to set the size of the buffers such that that’s unlikely to happen. In any case, it’s going to happen a lot less frequently than the allocations did in the old code. Code review, of course, welcome (see the new MIDIBuffer.hpp file).

Meanwhile, unless I hear back from testers soon, I’m inclined to submit to the library.

Chinenual · August 11, 2022, 9:44pm

I’ve submitted the new version (with the CC Expander) to the library. The original request from 9 days ago has not yet made it to the library - so not sure how long it will be before you’ll be able to get this via the library. Until then, you can install it as you have been installing the betas: