[Pacocreative]

Makes sense. Thanks for your input.

[Pacocreative]

Righty. Is Acousmonium based on Ircam’s SPAT? or DIY?

[Pacocreative]

Looks like the SFX Delay Pitch does not set any state variables.
Rushed release?

[Pacocreative]

Cool! When could we expect the release? I heard Feb. There’s a bunch of promised things I’ve been waiting for.

[Pacocreative]

SendData item 5 midimode 3

For some reason this does not seem to be working for my dials.
Is there anything specific that needs to happed in order for it to work?

[Pacocreative]

Gotcha, thanks.

[Pacocreative]

Yeah, understand it.
I actually tried implementing it with faders.
Even created a side-macro, independent from Matrix, whose only purpose was to handle faders.
But got to the same issue with not being able to intervene during a fadeout executed with “During”.
Which made me abandon this idea.

Last resort would be to have a separate slot macro running in a loop and slowly approaching the targets set by a Matrix macro.
But for some reason I don’t trust the looped macros for performance reasons.

[Pacocreative]

Following further investigation it seems that once Korpus Autofade (out) is in progress, there’s really no way to recall/break/stop it via macros.
I tested all possible combinations of available commands, both to Korpus and to the looper, and had no luck.

[Pacocreative]

Hey,

I’m having difficulties with controlling Korpus loopers with autofade via macros.
Specifically, I want to frequently put all loopers under Korpus to a long autofade, but be able to cancel the autofade and resume playback or recording on user action (via macro)

So I have something like that:

$SS_Head$ = 500
$SS_Tail$ = 5000
…
InsertSendMessage dt3 1 AutofadeAllWithLength 0 $SS_Tail$

and before the autofade is done, I want to use play, overdub or autofade 1 to cancel out the fade out and take it’s effect.

// trigger play
InsertSendMessage dt3 1 AutofadeAllWithLength 1 $SS_Head$
 

// or overdub
InsertSendMessage dt3 1 Overdub 1 

// or record directly in looper, not via korpus
InsertSendMessage fx9 1 Record $SS_Buffer$

This is where things get whacky.
It seems that when Korpus is during a long AutofadeAll fading out, when I click rec or overdub via Korpus UI it does cancel autofade and records properly.
But it does not happen so when using macros. During a long autofade out, I can start overdubbing, the autofade is not cancelled, the overdub ends, and afterwards the autofade comes to an end and mutes looper.

Also, it seems that macro korpus autofade is not handled properly.
Here’s an example:

// Looper under korpus, content recorded and playing
// Call a long autofade out
InsertSendMessage dt3 1 AutofadeAllWithLength 0 5000

// then call a short autofade in (manually, but from macro)
InsertSendMessage dt3 1 AutofadeAllWithLength 1 500

What happens is:
AutofadeAll gets cancelled from Korpus UI
Autofades are not cancelled in individual loopers

It means that there are probably discrepancies between UI operation vs macro functions.
I’d love some explanations and workarounds on how to deal with this.
Particularly, is there any way to cancel autofade that is in progress?

[Pacocreative]

It’s even a bit weirder.
I can’t seem to do it with learning, but I can pre-program 2 Matrices to take inputs from 1 controller.
I seems that whatever Matrix is the last in midi mapping configurations, this matrix will get midi learn inputs.

[Pacocreative]

Awesome! Thanks a lot for sharing these thoughts.

[Pacocreative]

Oh, this looks *very* useful to what I’m trying to achieve.
I just did not know it existed and did not imagine it could be done through talking to the dial!
Thanks a lot!

[Pacocreative]

Thanks for this, it’s helpful in terms of demonstrating a brilliant concept of reading values from the faders to dynamically change and update matrix UI. I learned a fair bit from it.

But it does not really solve the problem, so I am not sure if you understand what I meant?

Assume this scenario:

While using Project configuration midi mapping:
1. Midi-to-fader mapping is configured to “reach to change”
2. A track fader is on volume = 5 (range 0-100)
3. A midi knob is on value 90
4. When you touch/move the midi knob, the fader won’t abruptly jump to a value of 91, but you’ll have to move the knob down, to ‘catch’ the value of the fader, and only then it changes the volume – that’s the magic of “reach to change”.

While using macro scripting:
1. A track fader is on volume = 5 (range 0-100)
2. A midi knob is on value 90
3. When you touch/move the midi knob, the fader value abruptly jumps to 91, because “TrackVolume” function does not honor or allow for using “reach to change” option. A volume jump is a small problem in a performance setting 😉

And yes, I know I could try to write another routine in macro to emulate ‘reach to change’ behavior, but that’s producing plenty of unnecessary code, especially that I have a few dozens of knobs. More logical is to have this behavior implemented in “TrackVolume” and similar functions.

Is this still unclear?

[Pacocreative]

It’s both. Using Matrix as a macro ‘brain’, connecting external midi controllers to LL.

[Pacocreative]

Thanks for mentioning that. I wasn’t aware (yet) that there’s no variable to read the track state directly.
This would be helpful, but would require me re-implementing the “reach to change” functionality for each track I want to control with a macro.
I thought it makes more sense to have this implemented once in the definition of TrackVolume function on your side, and that’s what I suggested.

What do I want to achieve?
I want to control track volumes from a macro in a way that behaves the same way as If I set it up using project settings midi mappings set to mode ‘reach to change’.

A track volume midi-mapped through settings UI will use ‘reach to modify’ feature, but setting track volume via macro (currently) does not provide this option.
So there are abrupt jumps or You have to code ‘soft catchup’ each time you want to change volume via macro.

[Author]

Posts