Chinenual Development Thread

Development
21

I hadn’t considered that. My initial impetus was just for a recorder since there wasn’t anything in the library to solve that problem. There are a number of MIDI players in the library, so not sure building one would add much (but it would be a natural pairing with the recorder). Curious if you have any specific ideas on what could make such a MIDI player compelling.

1 Like
22

I was thinking about the 14bit midi recording - don’t think any players exist in Rack for that.

23

That may be a good enough reason to do a Player then :slight_smile:

24

Good news: I can reproduce the problem. Bad news: I can’t (yet) explain it.

If the problem is in my BPM → MIDI tick math, it’s this code - can anyone spot the problem?

#define MIDI_FILE_PPQ 960
#define SEC_PER_MINUTE 60
...
	void processMidi(const ProcessArgs &args)
	{
		total_time_s += args.sampleTime;
		// PPQ = ticks/beat;  BPM = beat/minute;
		tick = std::round(total_time_s * bpm / SEC_PER_MINUTE * MIDI_FILE_PPQ);

where “tick” is the event timestamp used on the actual MIDI data. The file is created with 960 ticks/beat and BPM is coming directly from Clocked’s BPM CV - and which matches its displayed tempo exactly (no rounding effects on that value). In my test, it starts to drift quite quickly (with a 240BPM test recording, it’s already playing early notes in the second measure… :grimacing:).

1 Like
25

I have had similar issues in the past, especially when working with smaller numbers where results got zero instead of a small number. So you haven’t shown the types of the varaiables but I would look in that direction.

1 Like
26

I don’t think I’m underflowing a variable - but just for completeness, here are the types of all the variables involved in that expression:

float bpm;
int tick;
float total_time_s;

and from ProcessArgs:

float sampleTime;
27

I am not saying it is the case, but I remember for that perticular case I went to doubles. But you should easily see with the debugger what is going on and if the numbers are corrrect.

1 Like
28

Thanks @robert.kock - I’ll put that on my list of things to look at.

29

@robert.kock nailed it. It really was just a matter of changing float math to double math.

While I was in there, I added support for tracking tempo changes during the recording.

@aetrion-music - please give it another try. You should see rock solid timing now. Version 2.0.0b5.

30

Nice! Will check tomorrow and report back.

31

Awesome, great news re expander. Thanks for considering.

1 Like
32

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

Great work!

1 Like
33

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

34

@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.

  1. 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.

  2. 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).

VCV_SPLIT
VCV_SPLIT150×766 54.6 KB

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

MIDI Recorder UI_Tweak
MIDI Recorder UI_Tweak804×450 143 KB

1 Like
35

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.

1 Like
36

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

6 Likes
37

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.

38

Amazing, thanks for adding the cc recorder expander.

1 Like
39

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

1 Like
40

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.