Turing Machine modulation feedback

[koswir]

Hi eh2k,
I'd like to provide feedback on the new type of modulation - Turing Machine.
Overall, it's a great idea and I'm super excited that you have added it.

In my opinion, an optional sequence reset is missing.
I have a few ideas on how to address this: there could be an additional line for "sync type" with options such as trig input t1-t4, MIDI clock start, or a timer.
The last option - timer - is used in some other modules, for example, sequencers from Robaux.
In these modules, the sequence is automatically reseted if the clock stops receiving triggers for a certain period of time.

Moreover, I love the FFT spectrum visualization and oscilloscope!
For the oscilloscope, it would be great to add horizontal zoom functionality!

[eh2k]

hi @koswir,

thanks for your feedback. I really appreciate that and I like your suggestions. I still have to think about the best place to put it.
E.g. sync type or the timer option could be introduced globally (midi&clock settings).

If you've noticed, the modulation popup has got a bit bigger, so that another parameter fits in there.
There was a 4th parameters that i have hidden after some usage, because I thought that this would only complicate it.

With the Turing-Machine modulation, my intention was initially just to bring in an alternative "randomizer". Following the same pattern, an arpeggiator or a miniseqencer or burst modulation, would not be a big deal.

The hidden parameter was a "trig-override" based on "TM Pulses Expander" logic.
Selection would be e.g. 1,2,3,4,5,6,7 but also 1+2, 2+4, 1+2+4+7. This means the modulation could generate also random triggers, and would bring the modulation thing to the next "complexity" level.

I can hardly say whether the function would be "overkill" and not easy to understand for someone who does not know how it is programmed internally. If you now say, ok, it's completely logical and not to confusing, I could add that in the next update.

[koswir]

The hidden parameter was a "trig-override" based on "TM Pulses Expander" logic. Selection would be e.g. 1,2,3,4,5,6,7 but also 1+2, 2+4, 1+2+4+7. This means the modulation could generate also random triggers, and would bring the modulation thing to the next "complexity" level.

Actually, I really like this idea. However, I'm not sure if it should be an additional parameter.
The MT Turing Machine, sends a trig from its first bit thru the pulse output, while the expander sends trigs from other bits. This makes sense when you have one Turing machine in the system and you want to send trigs to some different destinations occurring at different times or less frequently.
In the S&C, you created the possibility of adding a separate TM for each parameter, and each could have a different sequence.
Every one of them would have a trig override?
Maybe this trig override would logically be found on the I/O config subpage in Trig input?
The only problem than is which TM would the trig be from. Maybe from the one added to a pitch parameter?

I was also thinking that a glide/slew parameter would be cool, or even a glide triggered sometimes by one of Expander logic trigs?

I can hardly say whether the function would be "overkill" and not easy to understand for someone who does not know how it is programmed internally. If you now say, ok, it's completely logical and not to confusing, I could add that in the next update.

😄 imho o_c is not for ppl who do not like menu diving

[eh2k]

In the S&C, you created the possibility of adding a separate TM for each parameter, and each could have a different sequence.
Every one of them would have a trig override?

I thought to allow this only for the first parameter (piano keys). Consequently, the trigger and CV input in the IO-Config would then be fix to "- or internal".

The quantizer paramter in the IO-page is also somewhat special at the moment, as this also affects the modulation. However, it might make sense to show the quantiser parameter in modulation also, e.g. for CV input or TM ?!.

For the quantizer I was wondering whether it would be better to remove it from the IO-Config and only set it once globally for all v_oct signals. I don't know if anyone uses different quantizer at all (at least I never have).

Another approach would be virtual "cv/trig" routing between engines. For example, sequencer engines (TuringMachine) could be introduced as stand-alone engines (actually these would be CV engines with a cv & trigger output). As with the aux inputs, trigs and cv signals from other engines could be chosen as trig/cv-input in the IO page.

[koswir]

In the S&C, you created the possibility of adding a separate TM for each parameter, and each could have a different sequence.
Every one of them would have a trig override?

I thought to allow this only for the first parameter (piano keys). Consequently, the trigger and CV input in the IO-Config would then be fix to "- or internal".

Right. It makes sense to allow this only for the first parameter (I've called it pitch but piano keys is the better name). Although I wouldn't like it to fix IO-config's trigger and especially CV in as "- or internal". I have already used TM modulation with added CV input as a transpose before the built-in quantizer. That's why I have asked about TM reset - I wanted to sync it with an external, slower sequencer.

The quantizer paramter in the IO-page is also somewhat special at the moment, as this also affects the modulation.

I know that, and I love it! That was the first thing I checked after the update.

However, it might make sense to show the quantiser parameter in modulation also, e.g. for CV input or TM ?!.

I really like where quantizers are located right now.

For the quantizer I was wondering whether it would be better to remove it from the IO-Config and only set it once globally for all v_oct signals. I don't know if anyone uses different quantizer at all (at least I never have).

Well. I use different scales all the time. The obvious example is "chromatic", "x scale", "unquantized" on different machines. You can also combine similar scales like minor + pentatonic minor + harmonic minor.

In some cases, a global scale would be handy though. Maybe you could add a global scale option and it could be applied to machines by selecting "global" in the IO-Config's quantizer menu?

By the way, I would love to be able to change a scale by a selected CV. Maybe it could be set in a global scale menu?

Another approach would be virtual "cv/trig" routing between engines. For example, sequencer engines (TuringMachine) could be introduced as stand-alone engines (actually these would be CV engines with a cv & trigger output). As with the aux inputs, trigs and cv signals from other engines could be chosen as trig/cv-input in the IO page.

Yes, a TM engine would be dope! And it could have Key, Scale parameters with all the modulators!

[hotstuffwonkyair]

In the S&C, you created the possibility of adding a separate TM for each parameter, and each could have a different sequence.
Every one of them would have a trig override?

I thought to allow this only for the first parameter (piano keys). Consequently, the trigger and CV input in the IO-Config would then be fix to "- or internal".

The quantizer paramter in the IO-page is also somewhat special at the moment, as this also affects the modulation. However, it might make sense to show the quantiser parameter in modulation also, e.g. for CV input or TM ?!.

For the quantizer I was wondering whether it would be better to remove it from the IO-Config and only set it once globally for all v_oct signals. I don't know if anyone uses different quantizer at all (at least I never have).

Another approach would be virtual "cv/trig" routing between engines. For example, sequencer engines (TuringMachine) could be introduced as stand-alone engines (actually these would be CV engines with a cv & trigger output). As with the aux inputs, trigs and cv signals from other engines could be chosen as trig/cv-input in the IO page.

Yes! i love the idea of an internal Tmachine as CV engine that can be routed to the other engines , especially if its trigs can be selected from ext Trigs , int clock, OR its own lfo , mainly because having the TM as cv engine is excellent BUT fairly normal function BUT running it to trigger an engine with a different clock to whatever you are sequencing from externally makes for weirder more “buchla-esque” counter cycles.
I do love it as parameter automation as it is too btw :)