I’m building an Ableset plugin using React for the UI. With a few tweaks to my webpack compiler and using createPortal, everything is working like a charm!
I’m fetching the setlist from Ableset’s API since the song information has already been parsed. What is needed is each section clip’s end_time property which is used for customized jump logic. This property is always available unless a cue_point is placed at the start of the clip within Ableton. In which case, it seems to take precedent and the clip info loses its end_time property.
Is there an easy/efficient way to get this end_time property without having to use ableton-js?
Hmm, that’s an interesting one! If you’d like to get raw data about all clips, you can use the /api/setlist/debug endpoint. This returns all six steps in which cues and clips are parsed:
parsed: Step 1 – Concatenated points with meta. Clips following an auto cue are removed.
deduped: Step 2 – Deduped points by time, so an intro section clip “overwrites” a song marker.
grouped: Step 3 – Grouped points by song, with children.
groupedSongs: Step 4 – Removed all STOP and SONG END markers
sorted: Step 5 – Sorted by setlist meta.
filtered: Step 6 – Doesn’t include skipped songs.
The parsed property should contain all section clips and locators.
The parsed property already removes the clips following an automatically placed marker. I’ll see if I can add more information to the /debug endpoint, but in the meantime, it might be easiest to create an endpoint in your own script that queries ableton-js.
Thanks so much Leo! I’ve been using an endpoint of my own but it seemed redundant since Ableset already had a parsed list. I’ll look forward to that clip information being included in the “/debug” endpoint whenever it’s convenient to add it.
I can’t thank you enough for adding the scripts.js functionality to Ableset! It’s opened a world of possibilities that was not feasible before. You are awesome!!! Long live Ableset!
The latest beta of AbleSet (AbleSet 2.4.0-beta.8) now includes a raw property on the /debug endpoint which contains a list of all locators and section clips exactly as they were received from ableton-js.
Oh man, this timing couldn’t be better! I was in the middle of writing logic for a 2nd call to my ableset-js api. It’s awesome to have all the the data in one endpoint. Thanks a million!
@leolabs The only other thing that would seal the deal is if the activeSongId and activeCueId could be in this /debug endpoint. This may not fit into your specific usage but it’d sure be nice on this end!
Right now, I’m just making another fetch() call to /api/setlist which has the above mentioned info that I need.
To remove the need for an additional call to the API, I could expose the internal data stores on the window object so you can access them from your scripts.
I use TanStack Query to manage data from the API and that store is already updated in real-time so you wouldn’t have to open another socket to subscribe to changes.
The easiest way to access the data once would be to call it directly:
// You can omit the `window.` if you want, but I added it here for clarity
window.ableset.queryClient.getQueryData(["setlist"]).activeSongId
Or, to observe data, you could use:
const observer = new ableset.QueryObserver(ableset.queryClient, {
queryKey: ["setlist"],
select: s => s.activeSongId,
});
observer.subscribe(result => console.log(result.data));
I could also supply a simple hook if you want to use that data in a React component:
const { data, status } = ableset.useQueryData(["setlist"], s => s.activeSongId);
Some stores that are more focused on real-time updates use Zustand, and I could expose those as well:
Those hooks would be incredible for the front end code! Unfortunately, I still need that information for my express() based code. The server side code is required to make Transitions work because I’m triggering jumps based on the offset length of what I’m calling “Auxillary Sections.”
I’ve split your feature request off into a separate thread so we can discuss it there. I just released AbleSet 2.4.0 which exposes a bunch of useful objects on the global ableset object.
Apart from the ones I mentioned in my previous post, I’ve added getSocket which returns an instance of a socket.io socket in the given namespace. For example:
// Listen to all events
ableset.getSocket("setlist").onAny((event, data) => console.log(event, data));
// Listen to specific event
ableset.getSocket("global").on("songTime", (time) => console.log(time));
The following sockets are available:
global
setlist
lyrics
ablenet
playaudio12
timecode
settings
midiMapping
This also de-duplicates sockets so for example, all instances of the global socket use the same underlying connection. This should reduce the required bandwidth and load on the network.
I hope this helps and look forward to your feedback!