[Pacocreative]

This worked, thanks.

Here’s another crazy idea to consider.
Use GT as a sequencer to trigger MIDI messages or macros (one per track) instead of sounds. Wild.

[Pacocreative]

Hey,

Here’s a bit of a behaviour discrepancy I discovered.
Korpus recording, via UI & built-in midi mapping:

Press Rec - stars recording
Press Rec and hold - cancels recording and clears the buffer

This works as expected.
However when I try to mirror this in macro scripting:

// Record seems to work better via bult-in midi control
CaseBranch "K Rec"
//    Message "Record"
	// Record current looper / group
	InsertSendMessage dt1 1 Record
	BreakCaseBranch

CaseBranch "K Rec_longpress"
//    Message "Record Clear"
	// Clear current looper / group
//	InsertSendMessage dt1 1 Record // optional, tried to fix the issue
	InsertSendMessage dt1 1 Clear
	BreakCaseBranch

It does not bring expected behaviour.
It seems that Record status (in sync mode) goes from 0 -> 2 -> 1, and while trying to clear buffer in state 2, it does not really work as expected, I can’t stop and clear the recording, while it’s in blinking mode. Also not sure if I should be stopping rec additionally on clear. I tried, but it did not seem to help.

Is there any specific routine I need to do to mirror the built-in behaviour, or we arrived at some limitations?

[Pacocreative]

I think Normalize sent as a macro command to Granulaterre does not work.
I can normalize via UI, but can not via macro.

[Pacocreative]

Hey,
Here’s a few more requests as I worked with Granulaterre scripting.
Starting from the low hanging fruits.

1/ Overdub Mix level exposed for macro
2/ Track pitch exposed for macro
3/ RandomGrid to accept probability parameter (0. = none, 1. = 100%)
4/ Ability to lock rows, columns or cells from randomization
5/ Ability to provide programs by rows in a simple list/array format
6/ Better input routing — Is there a way to direct signal to GT coming from Inputs window AUX sends? Or other FX tracks? That would allow to pre-fx and have consistent routing with Korpus loopers.

Thanks for taking it into account somewhere in the future.

[Pacocreative]

Currently Matrix “case” and “case_longpress” can be programmed separately and are useful if you want to execute one action on short press down AND another one afterwards on longpress. However, this does not handle the case where you want to execute EITHER short press or longpress, but not both.

Here’s a small routine I use for programming single press vs longpress functionalities on Matrix macros so that when you longpress, the short press code is not executed. It’s usable for non time-critical actions of course, because the short press action is deferred to “case_up” event.

// in the head
Declare Local Once int $m_press_flag$ = 0   // Flag for detecting short/long

// in case branches

CaseBranch "K"
	$m_press_flag$ = 1
	BreakCaseBranch

CaseBranch "K_longpress"
	$m_press_flag$ = 0
    // put long press action here
	BreakCaseBranch

CaseBranch "K_up"
	// exec deferred short press action
	If {$m_press_flag$ == 1}
		// put deferred short press action here
		$m_press_flag$ = 0
	EndIf
	BreakCaseBranch

[Pacocreative]

Here’s a suggestion for the UI side of things.
I often find myself staring at the mixer colors and getting blind-sighted.
The reason for that is stark contrast because of AUX sends color codings combined with huge amount small identical items.
Color coding is great. But altering the backgrounds instead of text color would make it way more comprehensible at a glance, and less fatiguing.
This approach is already implemented in Acousmonium.

Here’s a comparison between current mixer color coding and how it looks with background approach.
https://www.dropbox.com/s/ahpyutcu1nj9frr/CleanShot%202025-01-02%20at%2019.05.12%402x.jpg?dl=0

[Pacocreative]

Here’s a bit of limitations I arrived at while scripting usage of Korpus.

1/ Missing overdub mix control (reported earlier)
2/ Expanded vs contracted view not stored in a preset -> this would be handy
3/ No Korpus autofade lengths available as variables -> this would be handy
4/ Limited information about groupings (details below)

Assume this situation:
Looper 1 – Group 1
Looper 2 – Group 1
Looper 3 – Group 1
Looper 4 – Group 1
Looper 5 – Group 2
Looper 6 – Group 3

Korpus currently reports the following variables:

End (number of groups)
Counter

This is sufficient to navigate across looper groups and accessing Korpus actions via macros.
But when scripting individual loopers settings and cycling through them, I arrived at the following problem:
Using $Korpus_data1_rank1_Counter_state$ only returns current group, but does not let you access information about how many loopers sit inside a group, and how many in total.

A primitive way of doing what I wanted was:

$Korpus_data1_rank1_Counter_state$ == 1    —> Acess fx1 1
$Korpus_data1_rank1_Counter_state$ == 2    —> Acess fx2 1

etc…

This works until you have several loopers in a group.

I think it would be great to have some more information in Korpus state variables about:
1/ How many groups there are (we got it)
2/ How many loopers are there in total, with their addresses and grouping info
3/ How many loopers (and which ones) are in a current group

I don’t have a specific solution in mind here, just sharing a usage case where it would be beneficial to have a bit more info available.
Theoretically I can hard-code specific cases in my macro, but it makes macros less universal and sharable.

Food for thoughts.

[Pacocreative]

Probably I’ll explore that option at some point.
I’m familiar with Max concepts and spent some time learning a few years back, but I never got to proficiency.
Then I got into Supercollider stuff, spent some decent time playing with Tidal Cycles and Haskell scripting.
Music has always been a hobby, so life and work used to take over.

Thanks for offering doing something for me, appreciate that.
I think that a recorded “hello world” tutorial for setting this up would be way more beneficial for the community.
There’s plenty of resources on Max itself, and LL is well documented, too.
It’s probably gluing it all together that will be the most time consuming part.

BTW, mind explaining the relationship between Max and LL?
Is it built as a Max app entirely, or it’s something else, custom coded, that somehow includes Max components?

[Pacocreative]

Since you mentioned Matrix and I took a look, it’s currently my go-to tool to setup all macros and midi.
Frankly, I do prefer Matrix + Macros vs setting up midi assignments in preferences.
The reason for that is a bit more flexibility and control, but also having everything in one place.
I’m also a visual guy, and seeing my workflow in front of me is a huge benefit.

I do get the logics behind how the preferences and midi assignments are designed, but it did not steal my heart.
Maybe I’m just spoiled with ‘click>learn>assign’ approach that has become a standard in established softwares.

Thanks for making it available.

[Pacocreative]

Here’s what I figured out:

InsertSendMessage fx1 1 Group 1
WaitUserAction 
InsertSendMessage fx1 1 Group 2

This always works.

But this is where it seems to break
1. Set a random group (ex 5.) via UI dropdown
2. InsertSendMessage fx1 1 Group 1 – works
3. Set a random group again (ex. 3)
4. InsertSendMessage fx1 1 Group 1 – does not work anymore, as if it remembered it’s still in group 1
5. InsertSendMessage fx1 1 Group 2 – this will work again, because we’re setting a different group than the last one via macro

The specific case I’m working on is writing a macro that will put 4 loopers into one group after they were manually assigned to different groups

Current workaround that works to set 4 loopers to group 1:

	InsertSendMessage fx1 1 Group 2
	InsertSendMessage fx2 1 Group 2
	InsertSendMessage fx3 1 Group 2
	InsertSendMessage fx4 1 Group 2

	InsertSendMessage fx1 1 Group 1
	InsertSendMessage fx2 1 Group 1
	InsertSendMessage fx3 1 Group 1
	InsertSendMessage fx4 1 Group 1

[Pacocreative]

The first one seems to be way more complex.
In a few cases the test macro worked, and my macro to put 4 loopers on 4 channels worked.
But in most cases it does not. I have no idea how to isolate it or where to look into.
No errors in the console.

[Pacocreative]

You are right, and I arrived at the same issues while programming a 150-buttons Matrix (!).
Playing currently with a layout for Novation Launchpad X, and setting up most of my workflows there.

If you choose to spend a New Year programming Logelloop, I guess you’re a freak… LOL
Happy New Year!

[Pacocreative]

I dug around again through settings and docu to make sure I didn’t miss something obvious.
Although I found a way to direct midi notes to a module or assign a midi variable listener, I can’t seem to find a way to get access to any midi note from a macro.

[Pacocreative]

I can confirm this worked.Not sure why it didn’t the first time.
Thanks for your help, Philippe. 🥂

[Pacocreative]

Well, I think I’ve investigated changing case branches to identify the buttons by string label.
That’s exactly what I wrote in my initial post, and as I remember it did not solve the problem.

Trying to repeat the same, but assigning strings as names:
SendData item dial 1 name “Vol 1”
SendData item dial 2 name “Vol 2”
SendData item button 9 name “ResetSpeeds”
SendData item button 32 name “StopAll”

I tried addressing CaseBranch both by ID or name String.

CaseBranch 32
// Your code here
CaseBranch “StopAll”
// Your code here

Dials stop working properly, but no error thrown in console.
Buttons stop working properly and I get error in the console:
dict: no dictionary named StopAll, cannot get value

Unless I made another mistake somewhere else.

[Author]

Posts