Lmms: Updating Zynaddsubfx to v2.5

[curlymorphic]

I have started work on updating our embedded Zynaddsubfx to version 2.5.

@fundamental has been kind enough to answer my questions on IRC :)

I really started this issue so we can keep track of progress.

It does add a new dependancy however , http://liblo.sourceforge.net/ I am unfimular with what is needed for this on a cross platform basis.

[tresf]

Liblo seems to support Windows.

From my understanding, we'll generally have @tobydox add it as a new library to the MINGW repository for Windows.

For Mac, I'd be building and bundling it (if Homebrew/MacPorts offers it, I add it to the bundle script, if not, I'd have to add it to our Apple build instructions).

For Linux, we'd probably just add it to our package dependency listing (perhaps something like Israel's packaging instructions)

[fundamental]

It might be possible to update Zyn for the 1.2.0 milestone.
The 2.5.1 release for zyn is almost purely a bug fixing release and that will be hopefully finalized in the next few weeks, so any bugs/issues found in upstream code can be fixed in pretty short order at the moment.

[tresf]

It might be possible to update Zyn for the 1.2.0 milestone.

Agreed. Really dependent on our team's progress, mingw included. :)

[curlymorphic]

Is it a problem to work on this for 1.2? Im not really sure of the time frame, If so I will do all that I can to help this issue.

[curlymorphic]

@tres sorry didnt see your last post

[badosu]

@tresf We really can't release 1.2.0 without -O3 back, I/we need to figure out what's going on.

[tresf]

@badosu, that is an unrelated winegxx/mingw combination that only applies to the vst_base plugin, specifically the RemoteVSTPlugin process (and dependent plugins -- VstEffect, vestige).

This -O3 (temporarily set to -O0)setting you are referring to is minor because it is only the process which interacts with the VST that suffers the bug.

Are you aware of performance issues related to the 1.1.3 build? 1.1.3 is a production release and it has that -O0 setting on for the VST stuff, so I'd think 1.2.x would follow suit (until we get it working again)

[badosu]

@tresf So are you saying only the compilation of vsteffect is unoptimized? If this is the case then it's fine.

I am unaware of complaints yet, so I really can't back my concerns.

[tresf]

Correct. My commit description is a bit misleading now that I re-read it... https://github.com/LMMS/lmms/commit/d14f4511b2235906ad66c375ed9d4ad34db0283c

[badosu]

@tresf Fine, sorry. I should have seen better, I read the description literally and was a bit over the top, lol.

[tobydox]

@curlymorphic : didn't read you're already working on this so maybe I did duplicate work in the master-zynaddsubfx-experimental branch. Nevertheless maybe it still helps you to figure out some integration issues. Alternatively you can help by working on this branch.

[tobydox]

@tresf : I'll take care of packaging rtosc and liblo for MinGW as soon as required.

[tresf]

@tresf : I'll take care of packaging rtosc and liblo for MinGW as soon as required.

:tada:

[curlymorphic]

Alternatively you can help by working on this branch.

@tobydox Let me know if theres anything you want me to look at.

[tresf]

@curlymorphic can you check out the branch he's referring to and see what else needs to be done?

[curlymorphic]

Sure will get on this today

[curlymorphic]

Still Wip.

[curlymorphic]

Been battling with this for days now. still cant get lmms to see zyn as a plugin. I think Its a linking issue.

[curlymorphic]

Ive not made progress on this in 10's of hours, so Im asking if anyone has any ideas.

What I have so far

git clone -b mZyn1 https://github.com/curlymorphic/lmms.git
installed liblo
sudo apt-get install liblo-dev

cloned built and installed rtosc

https://github.com/fundamental/rtosc

I have added the above 2 dependancy to

https://github.com/curlymorphic/lmms/blob/mZyn1/plugins/zynaddsubfx/CMakeLists.txt

With the build i linked above, When running lmms, zyn is not listed as a synth.

Experimanting, I have found that if in https://github.com/curlymorphic/lmms/blob/mZyn1/plugins/zynaddsubfx/ZynAddSubFx.cpp LocalZynAddSubFx is used, this is the result.

I have commented out large chunks of this file in order to get lmms to atleast see zyn as a plugin.

If https://github.com/curlymorphic/lmms/blob/mZyn1/plugins/zynaddsubfx/ZynAddSubFx.cpp#L460 is commented out, and rebuilt, lmms will list zyn as a synth, but obviously it does not run.

Im not sure what the problem is, and have spent hours experimenting trying to find out.

I would be really helpful if someone has some pointers please, maybe checking that I have linked it correctly would be helpful :)

@tresf @tobydox @Lukas-W

I

[tresf]

Here's the diff against master for those technically inclined.

• https://github.com/LMMS/lmms/compare/master...curlymorphic:mZyn1

Edit: @curlymorphic, I'm starting to wrap my head round the idea of updating by first looking back on previous commits per (none of which appear to be major)

• 9a993c4
• c38c705
• c920930
• e97ff90
• ... etc ...

Some changes that may or may not have made it into 2.5 upstream release:

• 0d76dc8 XML config file working directory
• 050af40 XML wrapper customization (reduce deps)
• 640f081 mingw64 fixes

And after that we seem to fall back into upstream commits per https://github.com/LMMS/zynaddsubfx/commit/ae6824cd9601cc41796b277d365f931a56e7721a, and so on.

-Tres

[tresf]

cloned built and installed rtosc

FYI for anyone trying to do this on precise, minor bug filed upstream. rtosc/#17

[curlymorphic]

@tresf can I ask for you help please to work out what needs to be to done and hows best to approach it?

Are you saying go thru all the commit logs for LMMS/zynaddsubfx and see if the patch has been aplied to the new code, if not apply it?

If that is the case, how should i do that, can that be done with git, or is it a manual process?

[tresf]

Are you saying go thru all the commit logs for LMMS/zynaddsubfx and see if the patch has been aplied to the new code, if not apply it?

Sorry for the confusion... No, I'm only stepping back on others' previous work to understand the plugin code and how we've integrated it a bit better.

[tresf]

can I ask for you help please to work out what needs to be to done and hows best to approach it?

I think if we compare 2.4.4 upstream against our 2.4.4 we could learn a bit about what was done to integrate Zyn in the first place and go from there. Furthermore, any major upgrades to Zyn would also result in some changes on our end, so I think we can learn from the past integration points and go from there.

But I'm entering into this blind as well, so take anything I say with a grain of salt. I'll continue researching and let you know what I find. :)

P.S. On precise curlymorphic/[..]/zynaddsubfx/CMakeLists.txt#L57 had to switch it to c++0x just like rtosc/#17

[tresf]

Ok... I'm googling my own problems now... got stuck on building ADnoteUI.cxx, which according to an old conversation with Mark, turned out to be a build problem with precise, fixed by building with 14.04. This is going to be a fun one. :)

[fundamental]

if you're having a ntk specific issue there was just a bug reported in regards to linking, so that may end up solving that particular issue once it is fixed.

[curlymorphic]

P.S. On precise curlymorphic/[..]/zynaddsubfx/CMakeLists.txt#L57 had to switch it to c++0x just like rtosc/#17

cheers. will change that.

turned out to be a build problem with precise, fixed by building with 14.04.

I though the vm I had been using for this the other week was 14.4, but my memory failed me, it was 14.10 :(.

thanks @fundamental will keep that in mind

[curlymorphic]

We can ignore my attempts at link rtosc and liblo to LocalZyn, because they are not needed there,
just on Remote as per

https://github.com/LMMS/lmms/compare/master-zynaddsubfx-experimental#diff-75559ad7a36e29cd9d13ed002f9738abR148

Ive got a diff of lmms/zynaddsubfx/master-upstream to lmms/zynaddsubfx/master

https://github.com/LMMS/lmms/compare/master-zynaddsubfx-experimental#diff-75559ad7a36e29cd9d13ed002f9738abR148.

Im not sure what has and hasnt been done in @tobydox branch, master-zynaddsubfx-experimental branch, when I do i diff it's huge, with no real hints in the commit log. https://github.com/LMMS/lmms/compare/master-zynaddsubfx-experimental

Im going to try on another fork of master-zynaddsubfx-experimental, and work through the above diff on 2.4, to see where we stand

[curlymorphic]

Some changes that may or may not have made it into 2.5 upstream release:

0d76dc8 XML config file working directory
050af40 XML wrapper customization (reduce deps)
640f081 mingw64 fixes

These fixes are all in the master-zynaddsubfx-experimental branch

[curlymorphic]

I have managed to break out of the rutt that I was in, and made progress, had to add the dependencies to zynAddSubFxCore. Now Lmms correctly lists zyn :) There is more work to go, but I have feedback now in the form of an error, so I have an idea of how to progress.

[musikBear]

Now Lmms correctly lists zyn :)

big :+1: !

[badosu]

Congrats @curlymorphic :-)

[curlymorphic]

The is now audio :)
Still more work before the ui,

[tresf]

The_re_ is now audio :)

:tada:

[curlymorphic]

zyn is now running as a remote process, with the ui.

Im not saying it's fully working, I need to test it for more than 10 mins, and do some clearing up, but initial signs look good.

[tresf]

Should testers snag a copy from your branch?

[curlymorphic]

not yet. give me a day or two to test it myself first. I have already found 1 problem with the gui callback, and wont be surprised if there is more i have to tweak yet.

Im just so happy to have the remote process stable for more than 3 seconds :)

[tresf]

Im just so happy to have the remote process stable for more than 3 seconds :)

:+1:

[curlymorphic]

The Ui now works and displays correct values, working vu meter, correct patch name etc.

atm I am aware of 2 issues that need sorting, and a clean up, before this is ready for initial testing.

crash on multiple internal instances, @fundamental has already kindly written a patch for zynAddSubFx, to allow it to run multiple instances, I think I just have to adjust our wrapper now.

crashes when loading specific presets, always the same presets, every time. I have not even started looking into this yet.

[tresf]

@curlymorphic if you want some help debugging, point us to the partially working branch. :+1:

[curlymorphic]

@curlymorphic if you want some help debugging, point us to the partially working branch.

sure, but I must warn you I would need a big clean up. there is still hack code in there

git clone -b "mZyn3Compare2.4Diff" https://github.com/curlymorphic/lmms.git

I keeping all changes to the lmms code, with the following exception.

In allocator.cpp I have temporarily raised the limit from 5mib to 100mib

merged the patch to allow multiple instances.

you will need to install the following

http://liblo.sourceforge.net/ , can be found in the ubuntu repo

rtosc https://github.com/fundamental/rtosc

[tresf]

git clone -b "mZyn3Compare2.4Diff" https://github.com/curlymorphic/lmms.git

Thanks!

I just wanted to offer because people like @mikobuntu, @Umcaruje or myself may be able to help debug a few things (like why the presets are crashing).

[curlymorphic]

(like why the presets are crashing)

:) that would be really helpful, I think I know what to do about the multiple instances. Ive just been starting at that code for far too long today. I will look into that tomorrow.

[curlymorphic]

• [x] Multiple internal instances :)

As for some presets not loading @fundamental has been really helpful on irc. I am going to start work on this now. I want a "working build" that can start being tested this weekend. It will probably still need some cleaning up. We will need windows dependancys before I will be able to make windows installers.

<fundamental> presets with effects?
<curlymorphic> erm ,not yet worked out the common denominator.
<curlymorphic> I have put zero time into that so far. I am going to start have an investigation now
<fundamental> both of those have extra extensions in the initialization path
<fundamental> well, those are very very likely to be the common denominator
<curlymorphic> nice, that could be saving me alot of time :)
<fundamental> effects for instance are not initialized until the part has been passed to the realtime thread
<fundamental> as they make use of the allocator which is RT thread only

[curlymorphic]

Finally at a stage with a build for testing. I am expecting bugs and it would be really good if they can be listed here.

@softrabbit @mikobuntu @Umcaruje

https://github.com/curlymorphic/lmms/releases/tag/zyn25.00

@unfa what os are you using? as your input on this will be of great use.

There is no windows build yet.

Although it is possible to load and play unfa-Spoken there is an issue with 1 of the 34 instances that stops the remote process(ui)'s from being opened, and I have not narrowed it down yet.

[mikobuntu]

Ok dl'd the source so I will get onto testing this. We have to remember that ZASF 2.4 is still buggy in the current stable build, so maybe this will address those issues aswell.

thanks Mikobuntu ;)

Date: Sat, 11 Apr 2015 13:59:25 -0700
From: [email protected]
To: [email protected]
CC: chrissy.mc.[email protected]
Subject: Re: [lmms] Updating Zynaddsubfx to v2.5 (#1860)

Finally at a stage with a build for testing. I am expecting bugs and it would be really good if they can be listed here.

@softrabbit @mikobuntu @Umcaruje

https://github.com/curlymorphic/lmms/releases/tag/zyn25.00

@unfa what os are you using? as your input on this will be of great use.

There is no windows build yet.

Although it is possible to load and play unfa-Spoken there is an issue with 1 of the 34 instances that stops the remote process(ui)'s from being opened, and I have not narrowed it down yet.

—
Reply to this email directly or view it on GitHub.

[tresf]

We have to remember that ZASF 2.4 is still buggy in the current stable build, so maybe this will address those issues aswell.

Agreed. Would be nice to close out some 2.4 items with this effort. :+1:

[curlymorphic]

Todays update.

Unfa spoken, now full loads, plays, can open all the ui's. afaik It now works as well as zyn 2.4

There is still the same instability when opening or closing the ui as 2.4.

The issue is caused by lmms hosting zyn internally, when there is no ui, when the ui is opened, the zyn parameters as saved to a file, the the internal zyn is deleted, then zyn is opened as an external process, then loads the saved parameters. It is this huge time game that I feel is causing the audio connections to be lost.

I have spoken with @fundamental on irc about this situation, and have been informed that this was necessary due to the integration of the ui and core code. This has nearly finished being separated.

I have suggested and fundamental confirmed that once this separation is complete, the best way to proceed is just to open the ui in the remote process, and leave the core audio in lmms, this should eliminate the current slackness of opening the ui.

I have an idea for a tempory fix that I am going to try tomorrow. It may not work, but i feel is worth the effort, even if it is only for this release.

btw the preset names now work (dont think i fixed this, If it was me its a pleasant side effect).

@tobydox you mentioned about sorting out the dependencies. I have absolutely no clue how to go about making the windows versions. It would be really nice to let our windows users test this before a merge.

@tresf

Agreed. Would be nice to close out some 2.4 items with this effort.

Are there any bugs other than the 2 above that really need to be included in this upgrade. I am more than happy to take a look at them, but would prefer to handle them as separate issues. both to keep the commits cleaner, and for my sanity.

[tresf]

Are there any bugs other than the 2 above

Not too many surprisingly.... #703 #1001 #1912

I know you can't readily test the Apple one... Myself or @eagles051387 would likely try that, but it suffers similar packaging issues of Windows, so that might have to wait... :)

[curlymorphic]

703 could well be down to the way we swap internal and external zyn's. I will just have to do the best I can, and hope it works on apple. Are there any cost effective ways for me to test apple builds?

1001 if im reading the bug reports correctly is now fixed

1912 time will tell. up until now I have assumed all segfaults were down to me not having zyn integrated correctly

[tresf]

Are there any cost effective ways for me to test apple builds?

There are some cloud services that let you rent one, but they're usually too expensive for my blood. I do have an OSX Lion VM (running on legit hardware -- because hackintoshes are simply too much work) that I use for creating releases. I could install Splashtop on it and you could use the Linux client to connect, but I'd rather we coordinate that together privately if we go down that route. The latency to europe would be pretty bad, so it may not be worth it.

Of course there is the option of buying an old Mac too... :)

[curlymorphic]

Of course there is the option of buying an old Mac too... :)

This could be the most practical, but lets wait and see if it's really needed. It's is possible that once we run the seperate ui, as mention above, that this bug fixes it's self.

[mikobuntu]

A couple of things that I noticed on initial testing:- I will make a more verbose report when testing more thoroughly.

(1) A pid file for ZASF is written to /tmp/ it seems on 1st opening an instance of ZASF, this pid file then cannot be overwritten on a new instance of ZASF being opened ( permissions are not the issue , it may be that the actual ref to the pid file is lost on opening a new instance of ZASF ) .

(2) rtosc is constantly running ( as seen from the terminal ) this may be a problem to users with little disk space as these outputs are often seen as debugging info on *nix systems and written to file ( needs more testing )

(3) using Unfa-Spoken for our test case may be causing problems as it was made on an earlier version of LMMS and there are some errors upon startup about missing plugins. We should use a clean room new project made on the actual version of LMMS that we are testing on...
*edit it only seems to be a missing sample in that project.

(4) Yes the 1st main bug #1001 seems fixed and further testing is still needed to see if the other bug/s are fixed esp #1912 ( mostly segfaults when clicking randomly within ZASF own gui... I will get back after I get more time for testing thoroughly...

[curlymorphic]

Thankyou @mikobuntu for taking the time and effort for this bug report.

(1) A pid file for ZASF is written to /tmp/ it seems on 1st opening an instance of ZASF, this pid file then cannot be overwritten on a new instance of ZASF being opened ( permissions are not the issue , it may be that the actual ref to the pid file is lost on opening a new instance of ZASF ) .

This is ZSAF way of checking there is only 1 instance running in a process. This is not the case for lmms.
I was trying not to change too much from upstream here. I simply removed the EXIT() after the test. If we are happy for me to change more, removing this check is doable, @tresf whats your thoughts on this please?

(2) rtosc is constantly running ( as seen from the terminal ) this may be a problem to users with little disk space as these outputs are often seen as debugging info on *nix systems and written to file ( needs more testing )

This is a simple fix, if we are happy to make the change?

(3) using Unfa-Spoken for our test case may be causing problems as it was made on an earlier version of LMMS and there are some errors upon startup about missing plugins. We should use a clean room new project made on the actual version of LMMS that we are testing on...
*edit it only seems to be a missing sample in that project.

I now have unfa spoken, iiac working as well as it did before the upgrade. I just have 2 memory issues to sort out, and I will post a fresh build.

[mikobuntu]

@curlymorphic No problem Dave ;) Oh one more thing, It might be specific to this build tho... we get an error when trying to drag a ZASF preset from the file browser :-

qUncompress: Z_DATA_ERROR: Input data is corrupted
at line 1 column "error occurred while parsing element"

All other methods of opening the presets seems to work on this build...

note on my own stable build "1.1.3" this issue doesn't seem to exist.

[curlymorphic]

we get an error when trying to drag a ZASF preset from the file browser :-

This issue is both caused and fixed on master. This was fixed with #1886, I have kept my fork based on tobys zynExperimental branch, as I am yet to work out how to make the pull request.

[mikobuntu]

@curlymorphic Ok that's cool .. I'l test with any branch that it requires, I'm sort of stuck in limbo anyway with my build due to errors with Carla not building on stable1.1 , but that's a whole different story.

[curlymorphic]

I have a latest build for testing, I think this should be ZASF 2.5 integrated as well as 2.4 is, well I have my fingers crossed :)

https://github.com/curlymorphic/lmms/releases/tag/0.01

[tresf]

I'm sort of stuck in limbo anyway with my build due to errors with Carla not building on stable1.1

I've had a similar problem and had to purge Carla (easy for me since I don't use it).

Unfa-Spoken for our test case may be causing problems as it was made on an earlier version of LMMS and there are some errors upon startup about missing plugins.

I'm pretty sure this is already resolved, but if we're missing plugins from one version to the next, we should file bug reports. :)

I have a latest build for testing, I think this should be ZASF 2.5 integrated as well as 2.4 is, well I have my fingers crossed :)

@curlymorphic tremendous!

[mikobuntu]

@tresf the Carla issue seems to be specific to stable1.1 , I was able to build it by adding the missing switch manually, but it could have been some error on m,y side with not cleanly updating before switching branches or something to that effect. Yeah it was only a missing sample from Unfa-spoken so we should be good to go.... cool @curlymorphic I'm building now as I speak, so hopefully I cannot find any bugs ..... ;)

[mikobuntu]

@curlymorphic Do you prefer we build with QT5 or is that irrelevant ? I ask because even setting the cmake prefix path to my QT5 libs still throws errors as though it is not found... Building with QT4 for now tho...

[mikobuntu]

@curlymorphic oops Crash almost instantly... I will run now in debug to see if I get any output....

edit ..Damn why is it that after a segfault you can never seem to be able to reproduce the same crash when using "gdb" ?

[curlymorphic]

so hopefully I cannot find any bugs .....

:)

Do you prefer we build with QT5 or is that irrelevant

I have been build with qt4, I must look into that, good catch.

@curlymorphic oops Crash almost instantly... I will run now in debug to see if I get any output....

Im really sorry, I will be back at my pc in about an hour, to see what ive done wrong,

[mikobuntu]

@curlymorphic I hav'nt been able to reproduce it again, but my test was vigirously opening and closing the ZASF GUI while playing in midi notes from my MIDI keyboard. The actual GUI was not opening right away but the GUI part where you pick between Advanced and beginner, then clicking Advanced, all still while playing notes. The openiong of the GUI gives quite a large CPU spike, which I think is the culprit for the segfault. I have a feeling that GDB slows the race condition or whatever the problem is down, therefore we don't get a proper segfault when debugging.... I think this was always an issue with ZASF so I'd say you have not introduced this @curlymorphic

[tresf]

IIRC, there were some lingering issues with QT5. Probably should have a separate issue to track for that rather than sending Dave off in the middle of the Zyn stuff. :)

[mikobuntu]

@tresf yeah sounds right, It will probably be a long time before QT5 is standard for most distros anyway.... In the meantime I have now managed to "freeze" LMMS/ZYN during debug mode...

[tresf]

@mikobuntu Thanks for helping debug this. :)

[mikobuntu]

@tresf My pleasure ;)

[mikobuntu]

I can reliably Crash LMMS now with this method:-

(1) Open a new project drag ZASF to BB_Editor
(2) Open Piano roll and draw in steps of 1/16th to fill 1 bar
(3) Play loop in Piano_Roll
(4) Now press rapidly the "Show GUI" button in ZASF ( you should move the actual ZASF internal instrument so that it is not being blocked by the popup window of ZASF remote plugin.
(5) you will see high spikes in CPU and LMMS will freeze ( in gdb ) and possibly segfault.

(6) for cleanup and retesting make sure to kill any remaining instances of RemoteZynAddSub ... a simple killall and tabbing on Re should work.

Below is the tail of "strace" at the moment of freezing...this may help? :

open("/tmp/qt_temp.J17725", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0600) = 41
fcntl(41, F_SETFD, FD_CLOEXEC) = 0
futex(0x7f2db4368020, FUTEX_WAKE, 1) = 1
futex(0x7f2d9c00a5e0, FUTEX_WAKE, 1) = 1
fstat(41, {st_mode=S_IFREG|0600, st_size=21757, ...}) = 0
fstat(41, {st_mode=S_IFREG|0600, st_size=21757, ...}) = 0
read(41, "\n lseek(41, 0, SEEK_SET) = 0
close(41) = 0
unlink("/tmp/qt_temp.J17725") = 0
futex(0x7f2d9c00a5e0, FUTEX_WAIT, 2, NULL

[curlymorphic]

@mikobuntu thank you so much for this.

I think I know the cause of the problems when rapidly opening and closing the ui, It is an issue we have currently with no real way to send messages to the mixer. what lmms does is simply delete instruments on gui click. If this gui click is pressed during the audio process loop the instrument is deleted while the mixer is trying to process it, causing the segfault. This is not exclusive to ZASF but all instruments. Deleting any instrument while playing has a chance of segfault. Once we can have just the gui in the external process, (maybe in the next minor release of ZASF ) this issue should be resolved.

off topic so i wont link the issues here, but this is the reason for not being able to deal with the moving and deleting mixer channels issues.

I have a feeling that GDB slows the race condition or whatever the problem is down

This could very well be true. From what I have seen in the last few months, processing power and number of cores does seem to effect the chance of these race conditions. I have been caught out before with code that works under gdb but not standalone.

[mikobuntu]

@curlymorphic No problem ;) also note I get a "FREEZE" when just rapidly opening ZASF gui without playing , with the output :- QProcess: Destroyed while process is still running ( this is an oldie too as I rem seeing this some time ago ). I'm going to test further with other instruments etc to see if there is anymore useful output.

[curlymorphic]

With the feature freeze coming I want to get this submitted. I have 2 questions.

1. I based my work on LMMS:master-zynaddsubfx-experimental, tobys branch, I am unsure of how you want this pull request, based on the same branch, or rebased against master.
2. afaik we still need the mingw dependencies for lo and rtosc. @tobydox is is this still the case.
   If I put the time In to learn mingw, I still cant build test builds, because I updated the depandancies on my VM, so now cant do windows builds at all.

@tresf do you have any thoughts on the above please?

[tobydox]

I'll deal with adding the libraries to the MinGW repository tomorrow.

[curlymorphic]

@tobydox Thank you :).

[tresf]

I based my work on LMMS:master-zynaddsubfx-experimental, tobys branch, I am unsure of how you want this pull request, based on the same branch, or rebased against master.

IIRC, we have to split the PR into two projects:

1. https://github.com/LMMS/lmms
2. https://github.com/LMMS/zynaddsubfx

I don't even know where to start on this though. @tobydox and @Lukas-W may be better advisers. :)

[tobydox]

@curlymorphic regarding instrument deletion: that's what the global mixer lock is for. If you lock the mixer, the GUI thread will block until the current period is rendered and the mixer does not access any instrument anymore. However this usually should be managed by the generic code for instantiating and deleting tracks and/or instruments.

[badosu]

@curlymorphic @tresf this looks like a case for using a git submodule pointing to our fork of zynaddsubfx.

Then you would pull the new version from zasfx via git submodule update and perform the local changes.

[tobydox]

@curlymorphic liblo now available as mingw32-x-liblo and mingw64-x-liblo packages. rtosc to come, having some difficulties with compiling ("src/cpp/ports.cpp:392:38: error: 'index' was not declared in this scope" etc.)

[curlymorphic]

@tobydox

However this usually should be managed by the generic code for instantiating and deleting tracks and/or instruments.

We seem to currenly have trouble with this deleting issue on most if not all instruments, it's not isolated to ZASF. I will take a look at the global mixer lock.

liblo now available

ty :)

rtosc to come

Thanks for your efforts.

[curlymorphic]

regarding instrument deletion: that's what the global mixer lock is for.

I did try to use Engine::mixer.lock() / unlock() but this still resulted in a priority inversion dead lock.
I have managed to over come this issue, with the use of 2 flags, to ensure that the audio buffer is allows to process before deleting the plugin.

Now in english

ZASF no longer freezes or segfaults when opening and closing the ui.

Steps I used to stress test this

1) open unfa-spoken
2) press play
3) click on a ZASF track to view instrument widget
4) spam my mouse button on the open ui button as fast as I can, while counting to 500.
5) wait a couple of minutes, while the ui opens and closes repeatedly
6) carry on listening :)

[mikobuntu]

@curlymorphic Good work 'Sherlock' on figuring this one out and fixing it :)

[Umcaruje]

@curlymorphic @tresf this looks like a case for using a git submodule pointing to our fork of zynaddsubfx.

Then you would pull the new version from zasfx via git submodule update and perform the local changes.

Zyn used to be a submodule, but then there were some complications for the users (see #315) so the idea was abandoned.

[tresf]

@curlymorphic,

Dave, we should also consider preventing click-jacking that button and disable it between timely operations, which should also help with the multiples in regards to race conditions.

-Tres

[curlymorphic]

Dave, we should also consider preventing click-jacking that button and disable it between timely operations, which should also help with the multiples in regards to race conditions.

nice idea :+1:
https://github.com/curlymorphic/lmms/blob/zynUpgrade/plugins/zynaddsubfx/ZynAddSubFx.cpp#L656

[tobydox]

The packages mingw32-x-rtosc and mingw64-x-rtosc are now available as well so you should be able to cross compile the new ZASF branch for Win32 and Win64. If there are any issues, please let me know!

[curlymorphic]

@tobydox tyvm :) do you have any suggestions for the ubuntu packaging of rtosc. It is not in the ubuntu repos, We was just discussing it in #1991

Im am going to test this under windows now:)

[Reaper10]

Will this update the preset list a lot are missing?

[musikBear]

@Reaper10 -a lot of zasfx presets.. -missing?
from where? and compared to what release version?

[tresf]

FYI, this may be superseded by Zyn 3.0 if the timing is right.

Disclaimer, not directly LMMS related but...

Call for testers with the new Zyn 3.0 branch is here: Edit: link removed. join the zyn 3.0 mailing list if interested.

[Spekular]

That looks gorgeous, holy crap.

[mikobuntu]

@tresf , I had the old link for the ZASF-3.0 branch and requested to be a tester there, I wonder if that will still be processed or should I try on their mailing list?

[tresf]

@tresf , I had the old link for the ZASF-3.0 branch and requested to be a tester there, I wonder if that will still be processed or should I try on their mailing list?

No clue. Pinging @fundamental.

[mikobuntu]

@tresf Thanks :)

[fundamental]

@spekular thanks

@mikobuntu You're on the list of responses, so you should get an email in the next day or so for the alpha build.

To all interested: If you're not on the 3.0.0 specific mailing list (and you're interested in the UI) I'd recommend signing up. There have been a grand total of 4 emails sent to that list, so it's a simple low volume way to keep track of progress.

[musikBear]

That looks gorgeous, holy crap.

yessss.. but you know what it also look like?
It look like i / you /us can throw everything ever 'studied' in respect to the zasfx-interfase over board :hammer:
Seeing this, and on top of that reading this today
http://lmms.io/forum/viewtopic.php?f=15&t=5358#p18928

I just wonder if using zasfx-3.0 as a VST would be a sane way to solve the integration issue -Unless its create an _absurd overhead_, ofcause. The obvious benefit would be VST access to the internal UI.
That access does btw _not_ work with the current dll version of zyn. 'All' (a lot of) the dials _are_ indeed included in the lmms-vst-ui, but none has any name, and doubt any is actually connected

[grejppi]

It look like i / you /us can throw everything ever 'studied' in respect to the zasfx-interfase over board :hammer:

@musikBear How so? The new UI will most likely retain the same functionality and concepts, just in a less cluttered way.

[liushuyu]

In my opinion, if we are going to update, maybe we would better update to
3.0 since that is the future :smiley:

But I wonder which graphics framework ZASF will use. Since many maintainers
from various Linux distributions are very concerned about this. Whether
ZASF is continue to use NTK/FLTK or switch to other framework like Qt,
WxWidgets or GTK.

Thanks :+1:

[tresf]

Here's the roadmap. Scroll down to "Workflow & Interfaces" to sign up for the mailing list.

http://zynaddsubfx.sourceforge.net/roadmap.html

@liushuyu from the homepage:

A major limitation in past versions was the fltk based user interface. The navigation of the fltk UI is complex and parameter changes do not have an obvious effect within the interface. A complete rewrite of the user interface has begin using the OSC api created in the 2.5.x series. This series will result in a single window user interface uniting the numerous views of the current UI. Parameters will have associated data visualizations easily available to help users understand how parameter changes should be expected to change their instruments without consulting documentation. This release is expected to support Windows, Linux, and OSX.

Some of this may be dated now, but here's some original Q&A about the GUI rewrite:

https://github.com/LMMS/lmms/issues/1911#issuecomment-88079906

[liushuyu]

Here's the roadmap. Scroll down to "Workflow & Interfaces" to sign up for the mailing list.

http://zynaddsubfx.sourceforge.net/roadmap.html

Subscribed. :+1:

@liushuyu from the homepage:
...
...
Some of this may be dated now, but here's some original Q&A about the GUI rewrite:

1911 (comment)

Thanks! That's valuable!

I am now more looking forward to the new version!

[unfa]

Is this issue alive? Any chance of running Zyn 1.5 / 3.0 inside LMMS?
I know we could use Carla Rack as a wrapper to use Zyn as a VST / LV2 plugin - but no automation would be possible that way AFAIK.

[Umcaruje]

Well, @curlymorphic hasn't been active for a while, so this issue is pretty much dead at the moment. From what I gather from #1991, there were issues on windows that were hard to fix because of the lack of debugging. Also, that PR is stale, needs rebasing, and the travis build is failing on it.

[mikobuntu]

Carla Rack is Linux only ( as an LMMS Plugin ) afaik @unfa

[tresf]

Carla Rack is Linux only ( as an LMMS Plugin ) afaik @unfa

Correct, for now it is Linux only. Related: https://github.com/LMMS/lmms/issues/2689

[unfa]

Crap. What can I do to push this issue forward?

I can help with debugging. I can test and provide backtraces and stuff.
(I might need some help with building though)

[tresf]

What can I do to push this issue forward?

The 2.5 merge likely won't happen from @curlymorphic's branch, so for starters:

• The OP's PRs need to be killed and resurrected here on the LMMS repo so that devs can collaborate on patches.
• The merge conflicts need to be sorted
• Windows needs to be fixed. It was crashing in previous builds and we had trouble debugging it due to lack of a working Windows debug environment.

Since all three of these are dev tasks, it depends how ambitious you (as in anyone) are.

[unfa]

I've e-mailed Curlymorphic and we've had a little converstaiton on the state of this issue. I'm quoting it below (leaving in only relevant pieces).

Me:

Hi, Curlymorphic!
(...)
I'm writing to ask you if you could come back and bring this issue to a happy end?
(...)
If it's not possible for you to finish this personally, could you at least help some other developer and guide him to understand the work needed to make this work?

You seem to be the only person who knows how this stuff is supposed to work - without your help we're stuck!

Curlymorphic:

(...)
I would have loved to have finished the Zyn upgrade, AFAIK it was working under Linux, but that was a long time ago, I have no idea what would be required to rebase with master now, many be not too much, as much of the work was outside the main LMMS codebase. The remaining issues, were Windows related, I’m not sure I remember the details, but I think it was a hard crash with the UI, At that time, there was no compiling or debugging in the windows environment, I simply have no Idea what the problem was. As there is now a working windows development chain, progress may be easier if someone chooses adopt this issue.

I no longer have any spare time, a career change, and returning to education keeps me busy. If any developer picks up this project I would be happy to pass on what knowledge I have, if I can remember the finer points. The commit log for the work I undertook is very verbose, agreeably far too much for a merge, but hopefully should allow anyone choosing to work on this issue, to be able to familiarise themselves with what I had tried previously.
(...)
I really miss being involved with the LMMS community, I learned a lot, and met some really nice people.
Yes, I think posting our correspondence would be a good idea, I was thinking of asking you the same question.

I shall try to answer any queries on the Zyn upgrade, to the best of my knowledge.

[fundamental]

Per the UI, it can be built/run out-of-process, so that may help debugging when the effort to update LMMS's zyn version is resumed.

[tresf]

Moving to the appropriate topic.

Quoting @fundamental at LMMS/lmms.io#241:

Since I've been summoned, I'll point to https://sourceforge.net/p/zynaddsubfx/mailman/message/35921306/ where I state that the [Zyn 3.x] source should be fully opened around mid-December.

Thanks for the update @fundamental.

[tresf]

This effort will be superseded by the Zyn-Fusion efforts spearheaded by @JohannesLorenz #4179. Closing as duplicate.