Control Surface Integration (CSI) Technical Feature Discussion

[airon]

Originally Posted by Sweetfoot

I'm building a simple dedicated MIDI controller for toggling snap, grouping and auto-crossfades.

I'd like to use toggle switches so I can feel if they're on without looking away from whatever I'm editing.

How do I setup my OST and ZON files to incorporate these toggles?

My OST includes definitions of both "on" and "off" messages from the toggles:

Widget snap
Press 9b 3c 63 8b 3c 63
WidgetEnd

Widget grouping
Press 9b 3d 63 8b 3d 63
WidgetEnd

Widget xfade
Press 9b 3e 63 8b 3e 63
WidgetEnd

and my ZON file is just triggering reaper actions:

Zone "Buttons"

snap Reaper "1157"
grouping Reaper "1156"
xfade Reaper "40041"

ZoneEnd

I know I'm approaching this wrong, but I can't figure out how to do it the right way

You could give it a go without the let-button-go message, i.e. the second triplet in each .MST "Press" line.
For example:

Widget snap
	Press 9b 3c 63
WidgetEnd

Or try Anypress. The actions seem to be ok. Double check your midi data as well.

[Sweetfoot]

Originally Posted by airon

You could give it a go without the let-button-go message, i.e. the second triplet in each .MST "Press" line.
For example:

Widget snap
	Press 9b 3c 63
WidgetEnd

Or try Anypress. The actions seem to be ok. Double check your midi data as well.

I figured it out shortly after I posted lol. I just defined the note-off commands as separate widgets so I could assign them to different commands in the zon file.

So:

Widget snapon
Press 9b 3c 63
WidgetEnd

Widget snapoff
Press 8b 3c 63
WidgetEnd

And then in the zon file, snapon triggers the command “enable snap” and snapoff triggers “disable snap”

I can’t believe it took me so long to figure that out

[airon]

There you go. Solved.


Geoff , there's this old problem about the send mutes.

Nofish tells me it may be this function to toggle the envelope-driven sends.

I'm still figuring out how to calculate the send_idx value to target specific sends. I'm hoping CSI will finally get me access to toggling envelope-driven sends, especially past the 8th send, which is the last one any actions cover. That's what I've had to use. The rest is only accessible via mouse click on the TCP/MCP.

Maybe that function works on the non-envelope-driven send mute as well ?

[Geoff Waddington]

New build is up.

CSI Exp.zip

Possible fix for SendUIMute bug.

[airon]

So far so good! The envelope-driven send mute toggles now work.

Thank you Geoff. This is very helpful indeed and will make things far easier for single tracks. This means a lot.

I'll be asking Justin and Schwa for more actions too, as only they work on all selected tracks. I'll ask for something like that for v4 of CSI. Don't want to upset the feature completeness for v3 here.

Or perhaps I missed something and this is already possible in CSI 3 ? I select a bunch of tracks and can mute/unmute sends on all selected with one button press ?

[Geoff Waddington]

Originally Posted by airon

So far so good! The envelope-driven send mute toggles now work.

Thank you Geoff. This is very helpful indeed and will make things far easier for single tracks. This means a lot.

I'll be asking Justin and Schwa for more actions too, as only they work on all selected tracks. I'll ask for something like that for v4 of CSI. Don't want to upset the feature completeness for v3 here.

Or perhaps I missed something and this is already possible in CSI 3 ? I select a bunch of tracks and can mute/unmute sends on all selected with one button press ?

Glad to hear it works !

[siniarch]

Originally Posted by andyp24

Hi Geoff and other SCE24 users

I've had a very prompt response from Luis. As you know, a simpler firmware with fewer screen options was designed in cooperation with Geoff, which should therefore be simpler for the user and more responsive.

The delay in delivering this has been from the firmware developer in China, who's been busy with other jobs and not prioritising Luis's work. However, Luis says that he's just heard that he may finally be finished with the new firmware (which was rewritten from scratch to optimise it) and he hopes to have something with us in the next week.

Good news
Andy

Hi Andy,
Thanks for updating everyone on the progress and sorry for my absence here. 2020 was a bad year, and ever since, I've been optimistic that the next year gets better, but alas, they keep getting worse. Hahaha.
Not to worry 2024 will be great. And no excuses. I'll keep moving forward.

So, I just wanted to update you and everyone else. Yesterday, Geoff received the new firmware. So provided it was all programmed as planned, CSI should be able to soon control the SCE24 with new firmware.

I'm actually visiting my mother, and wasn't expecting to receive the firmware yet, so I didn't bring my unit. But once I get back, I will also be testing it. If all is well, the unit is also designed to be able to be used as a Mackie C4 unit, albeit with 24 encoder instead of 32. So, I will test that as soon as I can.

I'll keep everyone posted.

[andyp24]

Hi Luis

That's great news, thanks for letting us know.

Looking forward to what the new firmware and CSI can do together!

Andy

[Geoff Waddington]

Just a quick update, I am currently working on the support for the new SCE24 firmware, so that when we get it, we should be good to go after a short testing period.

[Geoff Waddington]

Let's talk Selected Tracks.

We originally designed CSI to affect only one Selected Track in order to avoid unintended consequences when all Selected Tracks were not simultaneously visible on the Control Surface.

An oft requested change is to make it more a reflection of Reaper, where selecting a number of Tracks instantiates a temporary Group.

Since a primary CSI design goal is to reflect Reaper state, this seems logical.

What say you, good folk ?

[edit] Been looking into this a bit more -- this new functionality would be restricted to Volume, Pan, Width, Rec Arm. Solo, and Mute -- that seems to be what Reaper does, unless I'm missing something, automation already works as expected in CSI.

[andyp24]

Originally Posted by Geoff Waddington

Just a quick update, I am currently working on the support for the new SCE24 firmware, so that when we get it, we should be good to go after a short testing period.

Exciting news... Thanks

[Sound asleep]

This could potentially work for what I was talking about. Because I could select tracks, and save that collection of selected tracks within reaper, and it could recall those at the press of a button I could put in a toolbar, or something like that.

How would these selected tracks appear on an x32 console, for example, and what sort of functionality would be linked?

Also, what order would they appear in? I think the order would be the biggest drawback for this use case, because, let's say you add a new track somewhere, however the order is decided, most likely just sort by track number in ascending order, then this would change the location of the tracks on the x32, which would make the scribble strip wrong, but this probably wouldn't be much of an issue for me, as adding tracks that way probably wouldn't really happen for how I'd use it. But if I had my own x32 in my studio, then that would probably bother me.

[Funkybot]

Originally Posted by Geoff Waddington

Let's talk Selected Tracks.

We originally designed CSI to affect only one Selected Track in order to avoid unintended consequences when all Selected Tracks were not simultaneously visible on the Control Surface.

An oft requested change is to make it more a reflection of Reaper, where selecting a number of Tracks instantiates a temporary Group.

Since a primary CSI design goal is to reflect Reaper state, this seems logical.

What say you, good folk ?

[edit] Been looking into this a bit more -- this new functionality would be restricted to Volume, Pan, Width, Rec Arm. Solo, and Mute -- that seems to be what Reaper does, unless I'm missing something, automation already works as expected in CSI.

I think following what Reaper does makes perfect sense. Reaper often gives users enough rope to hang themselves, and I just see this is an extension of that.

I guess the question I have is, which track will actually appear on the surface (Track Name, Volume level, etc.)? I'm assuming the first track in the selection.

[Geoff Waddington]

Originally Posted by Sound asleep

This could potentially work for what I was talking about. Because I could select tracks, and save that collection of selected tracks within reaper, and it could recall those at the press of a button I could put in a toolbar, or something like that.

How would these selected tracks appear on an x32 console, for example, and what sort of functionality would be linked?

Also, what order would they appear in? I think the order would be the biggest drawback for this use case, because, let's say you add a new track somewhere, however the order is decided, most likely just sort by track number in ascending order, then this would change the location of the tracks on the x32, which would make the scribble strip wrong, but this probably wouldn't be much of an issue for me, as adding tracks that way probably wouldn't really happen for how I'd use it. But if I had my own x32 in my studio, then that would probably bother me.

Not how it would work.

Following the rule that CSI reflects Reaper state, the Selected Tracks would just appear as they normally do, so the Selected Track indicators on the Surface would light for any Tracks that were Selected and also visible on the Surface.

[Geoff Waddington]

Originally Posted by Funkybot

I think following what Reaper does makes perfect sense. Reaper often gives users enough rope to hang themselves, and I just see this is an extension of that.

I guess the question I have is, which track will actually appear on the surface (Track Name, Volume level, etc.)? I'm assuming the first track in the selection.

There would be no visual difference from the existing functionality.

The difference is, if you had Tracks 3, 4, and 6 on the Surface Selected, and you moved the Fader, Pan, pressed Solo, Mute, or Rec Arm, on any of those Selected Tracks, it would affect all the Selected Tracks, just like Reaper.

It would also affect Selected Tracks not visible on the Surface, just like Reaper -- if you couldn't see all the Selected Tracks in Reaper they would still be temporarily Grouped, and Muting one would Mute all Selected Tracks visible or not.

[MixMonkey]

Originally Posted by Geoff Waddington

The difference is, if you had Tracks 3, 4, and 6 on the Surface Selected, and you moved the Fader, Pan, pressed Solo, Mute, or Rec Arm, on any of those Selected Tracks, it would affect all the Selected Tracks, just like Reaper.

This sounds fine and I think most people would expect it to work this way

It would also affect Selected Tracks not visible on the Surface, just like Reaper -- if you couldn't see all the Selected Tracks in Reaper they would still be temporarily Grouped, and Muting one would Mute all Selected Tracks visible or not.

I don't see this as a drawback, again I think people would expect it to work like this. To me, it wouldn't make sense to restrict the selection to only those tracks that appear on the surface.

[Funkybot]

Originally Posted by Geoff Waddington

There would be no visual difference from the existing functionality.

The difference is, if you had Tracks 3, 4, and 6 on the Surface Selected, and you moved the Fader, Pan, pressed Solo, Mute, or Rec Arm, on any of those Selected Tracks, it would affect all the Selected Tracks, just like Reaper.

It would also affect Selected Tracks not visible on the Surface, just like Reaper -- if you couldn't see all the Selected Tracks in Reaper they would still be temporarily Grouped, and Muting one would Mute all Selected Tracks visible or not.

I don't think I explained it well:

Current State: if I select multiple tracks in Reaper, and my surface uses the SelectedTrack zone, the surface zeroes out. So there's nothing on the display, nothing assigned to the fader, etc.

My question was really, let's say I select 3 tracks: Gtr 1, Gtr 2, and AC Gtr...what would I see on the surface where the TrackName is for example? The first track selected? The last track selected?

[Geoff Waddington]

OK, have been looking into this all day, it seemed like it was doable, but it is anything but.

It could possibly be done for Solo, Mute, and Record Arm, but that's about it.

[Geoff Waddington]

Originally Posted by Funkybot

I don't think I explained it well:

Current State: if I select multiple tracks in Reaper, and my surface uses the SelectedTrack zone, the surface zeroes out. So there's nothing on the display, nothing assigned to the fader, etc.

My question was really, let's say I select 3 tracks: Gtr 1, Gtr 2, and AC Gtr...what would I see on the surface where the TrackName is for example? The first track selected? The last track selected?

Ah, there was no plan to change Selected Track Zones, the only goal was to get the Track Zone to behave more like Reaper with regard to Selected Tracks.

[jacksoonbrowne]

Originally Posted by Geoff Waddington

Not how it would work.

Following the rule that CSI reflects Reaper state, the Selected Tracks would just appear as they normally do, so the Selected Track indicators on the Surface would light for any Tracks that were Selected and also visible on the Surface.

On the X32, each track selects Button/LED is mutually exclusive.
Only one track can be selected at a time.

[Geoff Waddington]

Originally Posted by jacksoonbrowne

On the X32, each track selects Button/LED is mutually exclusive.
Only one track can be selected at a time.

OK, so the whole idea won't work for the X32 anyway.

Combining that with the technical difficulties of implementing it for Volume, Pan, etc., leads to us shelving multi select actions for the time being.

[Geoff Waddington]

I really want version 3.0 to be easily understandable.

I think folks are overwhelmed at times by our current technical explanations.

Maybe something like:

CSI is easy, if you just relax

Your MIDI or OSC Surface controls send signals to CSI/Reaper.

These signals are very technical, we need an easy way to use them.

That's what the .mst/.ost files do for us.

They allow us to give simple names to the signals -- e.g. Play for the Play button.

All good so far.

Now we need to tell CSI what to do when it receives a signal from the Surface -- e.g. Play.

That's what Zone files are for.

They connect the Surface controls to Actions.

For instance, it makes perfect sense to connect the Surface Play button to the CSI Play Action, so that when you press Play on your Surface, Reaper starts Playing.

Any way we can make this even simpler ?

Open to suggestions...

[Freex]

Originally Posted by Geoff Waddington

Let's talk Selected Tracks.

We originally designed CSI to affect only one Selected Track in order to avoid unintended consequences when all Selected Tracks were not simultaneously visible on the Control Surface.

An oft requested change is to make it more a reflection of Reaper, where selecting a number of Tracks instantiates a temporary Group.

Since a primary CSI design goal is to reflect Reaper state, this seems logical.

What say you, good folk ?

[edit] Been looking into this a bit more -- this new functionality would be restricted to Volume, Pan, Width, Rec Arm. Solo, and Mute -- that seems to be what Reaper does, unless I'm missing something, automation already works as expected in CSI.

Would there be a way to have a zone called "SelectedTrack" and "SelectedTracks "
Where when multiple tracks were selected a different zone was activated?
So we could have are normal zone and a hybrid zone, where certain actions are available.
So for me on the C4 if I had tracks 1,3,5and 7 selected I see a single send and returns for each splayed on D1-4 and C1-4 and could use a button or the rotarypush to move thru the sends of each track,

[Geoff Waddington]

Originally Posted by Freex

Would there be a way to have a zone called "SelectedTrack" and "SelectedTracks "
Where when multiple tracks were selected a different zone was activated?
So we could have are normal zone and a hybrid zone, where certain actions are available.
So for me on the C4 if I had tracks 1,3,5and 7 selected I see a single send and returns for each splayed on D1-4 and C1-4 and could use a button or the rotarypush to move thru the sends of each track,

Great idea !

Will have to think through all the implications, but love it !

[themathpotato]

How do I invert the state of a button LED? Eg. my F1, F2, ..., F8 buttons are mapped to custom Reaper actions which either have no state to prompt the LED to light, or have an "off" state. How can I make these buttons light up by default, with also the LED switching back off if it was mapped to a Reaper action whose state toggles to "on"?

Edit: Found it. InvertFB + [Button Name]

[MixMonkey]

Originally Posted by Geoff Waddington

Great idea !
Will have to think through all the implications, but love it !

This sounds like a great idea and an interesting variation on your "pinned" tracks concept - select a bunch of tracks, GoSelectedTracks and only those tracks appear on the surface - Done!

[Sound asleep]

Originally Posted by Geoff Waddington

Not how it would work.

Following the rule that CSI reflects Reaper state, the Selected Tracks would just appear as they normally do, so the Selected Track indicators on the Surface would light for any Tracks that were Selected and also visible on the Surface.

Oh I see. Too bad.

[Geoff Waddington]

Does anyone use:

TrackToggleVCASpill
TrackToggleFolderSpill

I now use Associated Zones for this functionality, are there any use cases that still require these Actions ?

[Funkybot]

Originally Posted by Geoff Waddington

Does anyone use:

TrackToggleVCASpill
TrackToggleFolderSpill

I now use Associated Zones for this functionality, are there any use cases that still require these Actions ?

Isn't that how we open the child tracks in a folder zone?

[Geoff Waddington]

Originally Posted by Funkybot

Isn't that how we open the child tracks in a folder zone?

Doh !!

Right you are, continue along, nothing to see here

[Geoff Waddington]

New build is up.

CSI Support Files.zip

CSI Exp.zip

Added support for SelectedTracks Associated Zone.

Zone "Buttons"
    
//  Encoder Assign Buttons

    Track                       GoHome
    Track                       Reaper _S&M_WNCLS4          // Closes all(!) FX chain windows
    Track                       Reaper _S&M_WNCLS3          // Closes all(!) floating FX windows  
    Pan                         GoVCA
    EQ                          GoAssociatedZone SelectedTracks 
    Global+EQ                   GoAssociatedZone Folder
    Send                        GoSelectedTrackSend
    Global+Send                 GoTrackSend
    Plugin                      GoSelectedTrackFXMenu
    Global+Plugin               GoTrackFXMenu
    Instrument                  GoSelectedTrackReceive
    Global+Instrument           GoTrackReceive

Zone Home
    OnInitialization ToggleEnableFocusedFX
    IncludedZones
        Buttons
        Track
        MasterTrack
    IncludedZonesEnd
    AssociatedZones
       SelectedTracks
       SelectedTrackSend
       SelectedTrackReceive
       SelectedTrackFXMenu
       MasterTrackFXMenu
       TrackSend
       TrackReceive
       TrackFXMenu
       VCA
       Folder
       SelectedTrackTCPFX
       SelectedTrackTCPFXTemplate
    AssociatedZonesEnd
ZoneEnd

Zone "SelectedTracks"
    DisplayUpper|            TrackNameDisplay { Track }
    Touch+DisplayLower|      TrackVolumeDisplay
    DisplayLower|            TrackPanAutoLeftDisplay
    Shift+DisplayLower|      TrackAutoModeDisplay
    Toggle+DisplayLower|     TrackPanAutoRightDisplay
    Alt+DisplayLower|        TrackInputMonitorDisplay
    Control+DisplayLower|    TrackRecordInputDisplay
    VUMeter|                 TrackOutputMeterMaxPeakLR
    Fader|                   TrackVolume 
    Flip+Fader|              TrackPan 
    Rotary|                  TrackPanAutoLeft RingStyle=Dot
    Toggle+Rotary|           TrackPanAutoRight RingStyle=Dot
    RotaryPush|              ToggleChannel
    Shift+RotaryPush|        TrackPan [ 0.5 ]
    Option+RotaryPush|       TrackPanWidth [ 1.0 ]
    Alt+RotaryPush|          CycleTrackInputMonitor
    RecordArm|               TrackRecordArm
    Shift+RecordArm|         CycleTrackAutoMode
    Solo|                    TrackSolo
    Mute|                    TrackMute
    /Select|                  TrackUniqueSelect
    /Shift+Select|            TrackRangeSelect
    /Control+Select|          TrackSelect    
    Option+Select|           TrackInvertPolarity    

    BankLeft                    Bank SelectedTracks -8
    BankRight                   Bank SelectedTracks 8
    ChannelLeft                 Bank SelectedTracks -1
    ChannelRight                Bank SelectedTracks 1
ZoneEnd

[MixMonkey]

Originally Posted by Geoff Waddington

New build is up.

CSI Support Files.zip

CSI Exp.zip

Added support for SelectedTracks Associated Zone.

If I'm not mistaken, this also adds support for the group Zone idea I floated a while back, thanks to the Reaper Action "Group: Select all tracks in group xx" Nice one!

Also, "SWS/S&M: Set selected tracks to group x (default flags)" opens up some interesting possibilities as a way of storing collections of selected tracks for recall onto the surface via GoAssociatedZone SelectedTracks.

[Sweetfoot]

I recently updated to CSI ver 2.0, and I'm not having trouble with tracks not showing up on my MCU and MCU xt in certain situations. For the sake of efficiency I'll refer to the MCU and MCUxt as "my control surface".

I have a set of custom actions that show and hide specific folder tracks based on their names (drums, guitars, bass, vox, ALL, etc.) When I was using the older version of CSI, my control surface would display whatever tracks were visible in reaper, starting with the first track visible in reaper on track one of the surface. If the number of visible tracks was higher than the number of tracks on my control surface (16) I could use the bank and channel buttons to scroll around.

Since switching to ver 2.0 I've noticed a change in the behavior. Here's where I run into trouble:

Let's say I have, for example, 24 tracks in a reaper project, and I scroll to the second bank on my control surface (so I'm seeing 9-24 across the surface). If I then I execute the action that shows only the 10 tracks that make up the drum folder, the control surface will display only the 9th and 10th tracks, as though it's starting at the second bank of tracks. I can't use the bank or channel buttons to scroll to the left to show the other tracks. I have to go back to showing all tracks, then scroll left to the first bank, then execute the "show drums" action again, at which point I'll see all 10 drum tracks.

Why has this behavior changed? How can I get my control surface to always start with the first visible track reaper on channel one of the surface? Do I need to tell CSI to return to "bank1" every time I run an action that changes which tracks are visible in Reaper? Why do the bank and channel controls stop working when I have 16 or less tracks visible in reaper?

[MT4U]

Originally Posted by Sweetfoot

Why has this behavior changed? How can I get my control surface to always start with the first visible track reaper on channel one of the surface? Do I need to tell CSI to return to "bank1" every time I run an action that changes which tracks are visible in Reaper? Why do the bank and channel controls stop working when I have 16 or less tracks visible in reaper?

Hi there.

I have a similar hardware configuration and CSI_EXP (3.0) is handling my Tracks Hide/Show scripts quite alright working with some 50+ channels.

I would really consider upgrading, really worth the effort and you may get fixes if there is some kind of bug.

Funkybot's excellent changelog https://github.com/GeoffAWaddington/.../CSI-Changelog will help you get there.

Good luck!

[Sweetfoot]

Originally Posted by MT4U

Hi there.
I would really consider upgrading, really worth the effort and you may get fixes if there is some kind of bug.
Good luck!

Ooh, I would like to update. Where do I download CSI v3? The link in Geoff's signature still takes me to v2.

Thanks!

[Sweetfoot]

Originally Posted by Sweetfoot

Ooh, I would like to update. Where do I download CSI v3? The link in Geoff's signature still takes me to v2.

Thanks!

Nevermind, I found it!

[Sweetfoot]

Originally Posted by MT4U

Hi there.

I have a similar hardware configuration and CSI_EXP (3.0) is handling my Tracks Hide/Show scripts quite alright working with some 50+ channels.

I would really consider upgrading, really worth the effort and you may get fixes if there is some kind of bug.

Funkybot's excellent changelog https://github.com/GeoffAWaddington/.../CSI-Changelog will help you get there.

Good luck!

I just updated to V3, and I'm still having the same issue. From what I can tell, there must be a specific "bank" value that is being stored, and when I change which tracks are visible in reaper, that "bank" value is not being reset to 1. Additionally, the bank and channel scroll buttons only work when there are more than 16 tracks visible in Reaper.

[MT4U]

Originally Posted by Sweetfoot

I just updated to V3, and I'm still having the same issue. From what I can tell, there must be a specific "bank" value that is being stored, and when I change which tracks are visible in reaper, that "bank" value is not being reset to 1. Additionally, the bank and channel scroll buttons only work when there are more than 16 tracks visible in Reaper.

Rightly so. I've just reproduced the behavior.

Have you tried the same approach with the Mixer window open in Reaper? It's working for me that way.

Also my scripts show/hide on both TCP and MCP.

          SetMediaTrackInfo_Value(CurTrack, "B_SHOWINTCP", state);
          SetMediaTrackInfo_Value(CurTrack, "B_SHOWINMIXER", state);

Do you have CSI configured to Follow TCP?

[Sweetfoot]

Originally Posted by MT4U

Rightly so. I've just reproduced the behavior.

Have you tried the same approach with the Mixer window open in Reaper? It's working for me that way.

Also my scripts show/hide on both TCP and MCP.

          SetMediaTrackInfo_Value(CurTrack, "B_SHOWINTCP", state);
          SetMediaTrackInfo_Value(CurTrack, "B_SHOWINMIXER", state);

Do you have CSI configured to Follow TCP?

I added a line to the .zon file for the MCU that turns on scroll link on initialization, is that what you mean by configuring CSI to follow the TCP?

Speaking of scroll lock, I noticed that if I select a track that causes scroll link to kick in, the tracks displayed on the MCU are always offset by 14 tracks. So for example, if I select track 17 in reaper, the MCU will show 30-45 instead of 17-32.

I have a bunch of mixing projects I have to get through right now, so I chose to revert to CSI v1 until I have some down time when I can take another crack at updating. Since reverting to CSI v1, everything is working properly again 🤷‍♂️

[Sonotor]

Originally Posted by JLP

I've tried to compile it by running :

g++ main.cpp -o CSI.so

But I got these errors :

/usr/bin/ld: /tmp/cc9tjJPx.o: warning: relocation against `SWELL_curmodule_dialogresource_head' in read-only section `.text'
/usr/bin/ld : /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/Scrt1.o : dans la fonction « _start » :
(.text+0x1b) : référence indéfinie vers « main »
/usr/bin/ld : /tmp/cc9tjJPx.o : dans la fonction « ReaperPluginEntry » :
main.cpp:(.text+0xbb) : référence indéfinie vers « ShutdownMidiIO() »
/usr/bin/ld : main.cpp:(.text+0x140) : référence indéfinie vers « csurf_integrator_reg »
/usr/bin/ld : main.cpp:(.text+0x34a) : référence indéfinie vers « hookCommandProc(int, int) »
/usr/bin/ld : /tmp/cc9tjJPx.o : dans la fonction « SWELL__dlg_cf__IDD_SURFACEEDIT_CSI » :
main.cpp:(.text+0x3b3) : référence indéfinie vers « SWELL_MakeSetCurParms(float, float, float, float, HWND__*, bool, bool) »
/usr/bin/ld : main.cpp:(.text+0x3c7) : référence indéfinie vers « SWELL_GenerateDialogFromList(void const*, int) »
/usr/bin/ld : /tmp/cc9tjJPx.o : dans la fonction « SWELL__dlg_cf__IDD_DIALOG_Page » :
main.cpp:(.text+0x416) : référence indéfinie vers « SWELL_MakeSetCurParms(float, float, float, float, HWND__*, bool, bool) »
/usr/bin/ld : main.cpp:(.text+0x42a) : référence indéfinie vers « SWELL_GenerateDialogFromList(void const*, int) »
/usr/bin/ld : /tmp/cc9tjJPx.o : dans la fonction « SWELL__dlg_cf__IDD_DIALOG_MidiSurface » :
main.cpp:(.text+0x479) : référence indéfinie vers « SWELL_MakeSetCurParms(float, float, float, float, HWND__*, bool, bool) »
/usr/bin/ld : main.cpp:(.text+0x48d) : référence indéfinie vers « SWELL_GenerateDialogFromList(void const*, int) »
/usr/bin/ld : /tmp/cc9tjJPx.o : dans la fonction « SWELL__dlg_cf__IDD_DIALOG_MidiSurface1 » :
main.cpp:(.text+0x4dc) : référence indéfinie vers « SWELL_MakeSetCurParms(float, float, float, float, HWND__*, bool, bool) »
/usr/bin/ld : main.cpp:(.text+0x4f0) : référence indéfinie vers « SWELL_GenerateDialogFromList(void const*, int) »
/usr/bin/ld : /tmp/cc9tjJPx.o : dans la fonction « __static_initialization_and_destruction_0(int, int) » :
main.cpp:(.text+0x555) : référence indéfinie vers « SWELL_curmodule_dialogresource_head »
/usr/bin/ld : main.cpp:(.text+0x5a4) : référence indéfinie vers « SWELL_curmodule_dialogresource_head »
/usr/bin/ld : main.cpp:(.text+0x5f3) : référence indéfinie vers « SWELL_curmodule_dialogresource_head »
/usr/bin/ld : main.cpp:(.text+0x642) : référence indéfinie vers « SWELL_curmodule_dialogresource_head »
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
collect2: error: ld returned 1 exit status

Not sure what to try to fix that. Do you have any idea? Thanks!

Nobody is able to have CSI on Linux?