Open Coupe70 opened 1 year ago
I just started having a look at this now. will get back with some updates later this week if successful
Ok, so by just looking at these files here: https://github.com/gluon/AbletonLive11_MIDIRemoteScripts/blob/main/ableton/v2/control_surface/components/session_ring.py (there is unfortunately some problem with a merge conflict that was not resolved, but its nice to have something to look at - adding the ableton/v2 code to the project might make autocomplete / linting eaaser @ideoforms ?). I was able to produce this:
The code is also injected here, following the same pattern but the auto reload seems to not be fully working, but didnt spend too much time stressing with it.
This produces this result
the nice thign is that it seems to work to do things like
Nice @MartinSahlen, keep us posted!
Auto-reloads are handled in manager.py reload_imports
, and each module you want to reload needs to be specified manually.
If you do look to submit a PR, please do add tests for any new functionality following the same format as the existing unit tests (in the tests
dir).
I will keep you posted but as @Coupe70 points out it may be good to get some clear scope of what the feature should do. I'm especially keen to understand i.e how much we should expect the box to dictate how AbletonOSC reacts to a change by i.e setting up listeners or whatnot. or even setting up a special routing that would "control" parameters / device or volume on the currently selected channels by the red box. or trigger clips etc. By this I mean - if AbletonOSC would control this we would need an APi that would receive similar messages as the tracks does to control them, but make sure to offset the channels/clips by the current position of the red box.
There are of course pros on cons and different ways to go about this, but if the goal of the project is to expose as much functionaluty as possible via OSC it would certainly be interesting to build something that would allow us to do "push-like" control easily.
Hi, I'm working on getting a visible and controllable session ring to forward its content (clip names, colors, etc.) to a virtual clip launch matrix. Unfortunately, both ways I tried were not really successful: building the whole logic around the session ring (listeners to all changes, handling of groups etc.) takes ages. But using scripts that already exist (e.g. the remote script for the Launchpad Mini, which doesn't have much more function than an 8x8 clip launcher matrix) and breaking it down to a purely virtual device that only retrieves the information fails due to dependencies all waiting to communicate with the actual hardware.
Now as I found this and as I already used AbletonOSC (thanks for your great great work here!) I wondered if you had any further progress here or plan to implement this?
EDIT: the only thing I actually want to create is a session ring, linked to whatever (e.g. a push), that pulls the clip names and outputs them to a separate screen. No interaction required, just extracting the information
Hi, I'm working on getting a visible and controllable session ring to forward its content (clip names, colors, etc.) to a virtual clip launch matrix. Unfortunately, both ways I tried were not really successful: building the whole logic around the session ring (listeners to all changes, handling of groups etc.) takes ages. But using scripts that already exist (e.g. the remote script for the Launchpad Mini, which doesn't have much more function than an 8x8 clip launcher matrix) and breaking it down to a purely virtual device that only retrieves the information fails due to dependencies all waiting to communicate with the actual hardware.
Now as I found this and as I already used AbletonOSC (thanks for your great great work here!) I wondered if you had any further progress here or plan to implement this?
EDIT: the only thing I actually want to create is a session ring, linked to whatever (e.g. a push), that pulls the clip names and outputs them to a separate screen. No interaction required, just extracting the information
This seems pretty trivial to achieve - A while ago I created some tooling (https://github.com/oslo1989/ableton-control-surface-toolkit) for this to make it easier to work the ableton api in more idiomatic and fully typed python, avoiding too hacky code.
You can have a look here https://github.com/oslo1989/ableton-control-surface-faderfox/blob/main/FaderFoxOslo1989Surface/control_surface.py, where I added some slighgly more advanced session ring functionality for my faderfox PC12. There is also an early start of a ableton OSC controllable surface based on the decompiled code here which also has some functionality implemented: https://github.com/oslo1989/ableton-control-surface-osc
The red box is an important tool when remote controlling the Live session view. It's part of the remote scripts for all grid controllers like Launchpad, Push, APC, ... I assume you are familiar with it, if not: https://remotify.io/sites/default/files/pre-built-scripts/kuala/red-box.gif
The red box is an API feature, functions are de/activate, size x/y and move up/down/left/right. In the example above it is 4x4, with a Novation Launchpad for example it would be 8x8 and show which 8x8 clips are controlled by the Launchpad. If you move the box by 8 steps the Launchpad shows and controls 8x8 other clips.
See it in action here: https://www.youtube.com/watch?v=3aX-7jmYJJU
It would be nice for AbletonOSC, also to limit the the number of active listeners as you only have to watch tracks and clips that are inside the box at the moment. AbletonOSC could only provide the mentioned visual functionality of the box and leave the handling of the listeners to the client OR assist the client by adjusting some things internally when the box is moved.
Send me a message if you want to go into details.