Yes. I can confirm - quantize mode isn’t doing what it’s supposed to. I’m using this as an excuse to refactor the code and introduce a bunch of unit tests for the quantization (both straight quantization and the original tintinnabulation modes).
1 Like
Hurray for unit tests. The problem (a problem?) seems to be limited to the case where the pitch in a reference chord is non-12-TET. The computed frequency used the wrong chord note’s pitch relative to 12-TET. Should be easy to fix. But I’m going to flesh out the tests to see if I can find anything else before I inflict a new beta on you, so tomorrow soonest. Standby!
3 Likes
New version for testing. This fixes the bug @strangebuttrue reported. The innards of Tint have been simplified considerably and there’s now a rash of unit tests to confirm behavior. Give it a go!
Fixed behavior:
At first I thought the quantize mode was still not working, but I suppose that the quantizer will quantize to octaves of the Chord input values. Right?
That probably makes sense if the primary intent is to manipulate v/oct CVs. If the desire it to quantize to arbitrary CV voltages, this behavior would not be appropriate, but that is okay. In such cases I would continue to use the SIM Coerce module… unless I am missing something.
1 Like
Yes, I think that’s the right way to think about it. Tint uses the reference chord to layout notes in a normalized octave, then replicates that quantization throughout the full voltage range, repeating the pattern for every octave.
1 Like
Has anyone seen or have there been any reports of Rack crashes on the the latest Chinenual build? I disovered this morning that quite a few of my recent patches cause rack to crash but with no log stack trace. In such cases, the last thing in the log is the Chinenual OpenSans-Bold.ttf load. This may just be coincidental, but it does also appear that the crashes seem to involve patches that have Chinenual Tint and/or NoteMetermodules in them. My Chinenual version is 2.4.0 which is the library version.
Thanks.
Oh no. 2.4.0 did have a couple of buffer overflows that I fixed after testing under the address sanitizer - you may be hitting one of those?
I have a new version teed up for the library (which is identical to the 2.4.1-beta3 I posted last week). Can you switch to that for a bit and see if you still have crashes?
Okay, I will give that a try. On some of my crashes the last thing in the log file is: Creating module widget Chinenual NoteMeter.
2.4.1-beta3 fixed the problem. There is a chance that I applied this last week but then inadvertently did an “Update All” for the newest batch of other updates and that “upgraded” me to 2.4.0 .
1 Like
Good news. Sorry for the crash, but glad to hear that the version about to hit the Library has it fixed.
1 Like
Yep, and it was NoteMeter that was the culprit.
The fixed version of the plugin is now in the library - for those of you affected by the Tint and NoteMeter crashes on Windows, it’s now safe to install from the library. This version is labeled 2.4.2 and rolls up both that fix and the new support for non-equal-temperament reference chords in the Tintinnabulator.
1 Like
Working fine! I still love the Tint quantize to a chord ability.
1 Like
My first post of a patch/music to the VCV forum. This is a hybrid patch - developed mostly in raw VCV, but then morphed into a hybrid. I use Logic Pro to control scale and chord for the arpeggiations (the patch originally used Aaron Static’s ScaleCV and ChordCV). I record audio in Logic and post-process that audio to orchestrate gain changes and add some additional effects (some filtering, flanging and reverb). Not sure posting the vcv patch makes any sense since it requires “external” instruments/effects. I’m sort of happy with the end result.
3 Likes
Lovely
1 Like
Another “scratch my itch” module - Inv - which produces melodic inversions.
I could not find anything in the library to do this directly (though I’ll bet you’ll tell me there are some :)). The closest I was able to find was Count Modula’s Voltage Inverter - but that inverts around a fixed pivot of 0V so would require some pre and post fiddling if you want an inversion around something other than C4. Inv’s claim to fame is that you can specify the inversion pivot frequency. Note that this is simple chromatic inversion. I am not clever enough to think of a way to handle proper tonal/diatonic inversion (since that would seem to be purely based on relative motion and I can’t think of how to tell the module where to “start” the inverted melody). Perhaps you’ll have some ideas?
If you want something approximating diatonic inversion, try quantizing the output to the desired scale:
Available for testing at:
5 Likes
Another scratch my itch set of modules. I had a need for a way to share sort criteria across multiple polyphonic splits. This is something Aria Salvatrice’s Splort module did well. So I’ve implemented two modules (a split and a merge) adopting her approach to linking the modules through a LINK cable.
It’s ready for testing - get your copy at
SplitSort
Splits a polyphonic cable and optionally sorts the channels, with possibility to share sort criteria with another SplitSort or MergeSort.
Buttons:
- Sort - sort the signals when pressed.
Inputs:
- In - the polyphonic cable to be split.
- Link - if connected, sort based on the values in the Link rather than the values in the Poly. This allows multiple modules to be sorted in the same order. Can be daisy chained - the first module in the chain determines the sort order.
Outputs:
- Out - 16 separate outputs, one for each channel of the Poly input.
- Link - a polyphonic signal that can be used to control the sort order of another MergeSort or SplitSort module. Can be daisy chained - the first module in the chain determines the sort order.
For example, a set of three SplitSort modules can be used to sort incoming MIDI note/gate/velocity all sorted by the same V/Oct criteria:
MergeSort
Merges a set of monophonic signals into a polyphonic cable and optionally sorts the channels, with possibility to share sort criteria with another SplitSort or MergeSort.
Buttons:
- Sort - sort the signals when pressed.
Inputs:
- In - 16 separate inputs, one for each channel of the Poly output.
- Link - if connected, sort based on the values in the Link rather than the values in the Poly. This allows multiple modules to be sorted in the same order. Can be daisy chained - the first module in the chain determines the sort order.
Outputs:
- Out - the polyphonic output.
- Link - a polyphonic signal that can be used to control the sort order of another MergeSort or SplitSort module. Can be daisy chained - the first module in the chain determines the sort order.
8 Likes
Nice, this kind of module gets asked about every so often!
2 Likes
I like the general concept, I can see how both split sort and merge sort can be useful. And sorting one poly signal based on another also makes sense. But I see two potential issues
- Daisy chaining can introduce sample level timing differences, which may or may not be a problem. An ideal solution would keep all poly signals in sync
- You may already have a set of poly signals (MIDI in for example) that you want to sort. You might want to sort without merge or split.
I think a more general purpose module would be one that sorts the channels, without any merge or split. You could have multiple pairs of poly input/output, where each input is sorted and sent to the output. You could have a link button that if enabled, sorts all poly inputs based on the values in the first input.
I’m thinking of 8 inputs arranged vertically on the left, and 8 outputs on the right. There could be two link buttons, one at input/output 1, and another at input/output 5.
- If no link buttons are enabled, then all inputs are sorted independently from the others.
- If link 1 is enabled, and link 5 is disabled, then all 8 inputs would be sorted by the values at input 1
- if both link 1 and link 5 are enabled, then inputs 1-4 would sort based on 1 values, and 5-8 would sort based on 5 values
- if link 1 is disabled and link 5 is enabled, then inputs 1-4 would sort independently, and inputs 5-8 would sort based on 5 values.
Such an arrangement provides a lot of flexibility, and the sorted outputs remain in sync down to the sample level.
If you choose not to create this, then I may create the module for my Venom plugin. But I see no sense in duplicated effort.
2 Likes
I like this idea. I was thinking of adding a Poly->Poly sorter, but your idea of having 8 all in one module is much nicer. I’ll implement this (or something very similar).