Would love it if I could turn this off or define my own default patch.
I couldn’t figure out how to use the sequencer in Reason (but the front/back panel wiring and patching … sure, figured that out no problem ) , or do anything in Live aside from accidentally bring in an audio plugin and then have it make a few random beeps from key presses, when I was completely new to DAWs.
That is what the template file is for, documents/Rack
I think the best would be to present a first time user a black SQUONK just in the middle of the second ROW
But if Fundamental had a quantizer…
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.
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.
Rack 1.0 issues
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);
edit: to be clear
Returns true is the channel is valid and a voltage set on that channel.
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.
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.