I think the best would be to present a first time user a black SQUONK just in the middle of the second ROW
6 Likes
But if Fundamental had a quantizer… 
2 Likes
Is 4 threads maximum? I have 6 physical cores, and would might like to run up to 5 threads, unless the diminishing returns makes that a stupid idea?
The maximum is your number of logical cores. With 5 threads (or maybe even 6), you will likely be able to run more modules.
2 Likes
Wrote custom engine multithread code, which removes the OpenMP dependency. This performs and behaves the same as the old code because it’s the same thread model.
5 Likes
I have made a first pass at migrating the AH modules to the unstable v1 API and an implementation of support for polyphonic cables. So far so good and it works pretty well.
Everything is fine while I can control how the channels are populated; I can ensure that the channels are sequentially populated with no gaps. But with a multiplexer the user can opt not to connect a channel, creating gaps.
Gaps are a problem since 0V is a perfectly valid voltage, but I would like to pick up the absence of a signal and exclude that channel. So can we have something like:
bool isChannelConnected(int channel);
Thanks!
edit: to be clear
Returns true is the channel is valid and a voltage set on that channel.
1 Like
Since pictures > words:
This is OK
This might will cause problems
This is a design issue with your Arp interface. You should have a GATE input if you want to allow it to arpeggiate arbitrary channels.
Or change the design of your MuxDeMux.
Since the poly channels in Rack v1 are not intended to have gaps, don’t multiplex gaps in.
Nah, his behavior for the Muxer is correct. Users need to be able to assign the channels they need, with 0V for unpatched channels.
1 Like
Also, it is purely a test rig for me. It will not be part of the v1 release as I expect Fundamentals with have something and I see no reason for multiple versions of the same 10 lines of code.
It’s always nice to have alternatives, so you might as well since you have the panel made already.
Okay. That sounds at least consistent with how the MIDI-CV interfacing seems to work, so I can understand the rationale.
The fact that it first came up with this particular module is rather irrelevant. Any module which has to work with arbitrary patching has to know how to interpret the state of the port(s). With monophonic cables it is much easier since we can trust isConnected() to reduce invalid inputs.
v1 running on windows. Thanks Andrew!
The “best” way to write a poly-supporting chord generator is to have a 1V/oct and GATE output, and a context menu item selecting the fixed number of polyphonic channels. The number of output poly channels should not change, because changing the chord should not kill the release of previously-held notes. If the user selects more poly channels than you have in your chord, you could optionally do more advanced channel assignment when the new chord is “played”. How you do that is up to you. Alternatively, you could forget the GATE and guarantee that all poly channels have some relevant note on it, either by duplicating notes or by adding more octaves.
Core MIDI-CV will support Reset, Rotate, Reuse, and Reassign.
1 Like
Alternatively, you could forget the GATE and guarantee that all poly channels have some relevant note on it, either by duplicating notes or by adding more octaves.
This is pretty much how the AH chord generators work right now.
Anyway - thanks for the advice. I’ll see how to best move forward and it’s clear on the best way for the modules receiving poly cables.
It looks like the audio threads (now plural) still run at default priority?
Yes. I have not yet designed criteria/goals for testing thread priority.
Major Thanks