assert in creating undo operation group

[spamatica]

Hey Tim, it's winter, I'm back for a while. ;)

Apart from a pretty long hiatus with other projects and life in general, I've been on a slow mission to replace Airwave, the VST-bridge I've been using the last few years. It has had some nagging bugs (got worse recently too) and the guy behind stopped developing it so it was really long overdue... Still need my windows drum plugins...

So.. I've been looking to replace it with yabridge and was thinking how to get it in and using Airwave for old projects for compatibility.
I hope I'm not jumping to conclusions now but yesterday I discovered that airwave and yabridge are so compatible that they mask the plugins in the same way. Meaning that my old projects seem to run just fine with only yabridge enabled!

Well, enough about that.
What I really wanted to ask about was this assert:
muse4: /home/ddskrjo/dev/muse/src/muse/undo.cpp:2582: MusECore::UndoOp::UndoOp(MusECore::UndoOp::UndoType, const MusECore::Track*, int, MusECore::CtrlList*, MusECore::CtrlList*, MusECore::CtrlList*, MusECore::CtrlList*, MusECore::CtrlList*, bool, bool): Assertion 'type_== ModifyAudioCtrlValList' failed.

I get this when selecting multiple tracks and clicking on the ARM button on one of them.
When you have only one track it simply sets it for the track. But with multiple it seems to want to create an undo group.
Now, there is unfortunately several things I don't understand about the undo system. Complictated stuff, I know.

This case is no different. Is the rec-enable supposed to be undoable, or is it a necessary means to propagate the operation to the engine?
Reading the comment for the single arm it looks that way, but maybe, since it affects multiple tracks it is intentional to make it undoable.
Seems the UndoOp selected:

void Song::setRecordFlag(Track* track, bool val, Undo* operations)
{
  if(operations)
  {
    // The undo system calls setRecordFlag1 for us.
    operations->push_back(UndoOp(UndoOp::SetTrackRecord, track, val, 0, 0, 0, 0));
  }

simply gets the wrong constructor. But I'm not sure there is a right one, possibly not created yet?

[terminator356]

I discovered that ye olde FST project is very alive and well.
https://git.iem.at/zmoelnig/FST
I've not looked any deeper into it, though.
Remember we used to have a working trusty FST module, but it seems
to have been removed at some point, or else I can't seem to find it in our source tree.

So it seems that on your system, this code...:

// The undo system calls setRecordFlag1 for us.
operations->push_back(UndoOp(UndoOp::SetTrackRecord, track, val, 0, 0, 0, 0));

...is actually calling the wrong Undo constructor...:

UndoOp(UndoType type, const Track* track, CtrlList* eraseCtrlList, CtrlList* addCtrlList,
CtrlList* recoverableEraseCtrlList = nullptr, CtrlList* recoverableAddCtrlList = nullptr,
CtrlList* doNotEraseCtrlList = nullptr, bool noEndAudioCtrlMoveMode = false, bool noUndo = false);

...instead of the correct one:

// At least four of these arguments must be supplied even if less than four are used,
// to avoid ambiguity with the route_from/route_to version because class Route has
// a constructor that takes a track pointer and a constructor that takes an integer !!!
UndoOp(UndoType type, const Track* track, double a, double b, double c, double d = 0.0,
double e = 0.0, bool noUndo = false);

Hm, I stepped through it. On my system it calls the correct constructor.
(Man, I hate making these Undo constructors, there are tough ambiguities sometimes.)

If possible could you try something like this:

// The undo system calls setRecordFlag1 for us.
operations->push_back(UndoOp(UndoOp::SetTrackRecord, track,
double(val),
double(0), double(0), double(0), double(0)));

Maybe that would force it to call the right constructor?

[terminator356]

I discovered that ye olde FST project is very alive and well.

Er, actually I just checked and it is really just a header file with some source code
to test hosts and plugins for unknown opcodes.
Definitely not the same as the old FST.

Might I recommend trying DSSI-VST again?
I mentioned before that some issues with the kernel were fixed and
it tested just fine recently after being broken for a long time.

[spamatica]

I'm not sure but I think I got to testing DSSI-VST when you mentioned it but couldn't get it to work.

In anyway I think yabridge is the way to go. Very active developer and the compatibility looks excellent. It's not as easy to get up and running as DSSI-VST though (or Airwave for that matter).

Regarding the assert, I'm gonna test casting the parameters, probably that is it, compiler changes maybe.

[spamatica]

Yep, that fixed it. Same is on the input monitor button. Thanks!

[terminator356]

Yay. I will check all the other places using those constructors.
Perhaps it might explain why some are reporting weird crashes...