Zyn - Blank Instrument Bank

[musikBear]

(win 32xp)
Read this
http://linux-multimedia-studio-lmms.996328.n3.nabble.com/new-zasfx-how-is-the-quality-any-aspects-discuss-td9642.html
Toby has upgraded zasfz (zyn) so this strange zyn-bug may not be present, if it is, the wiki need something temporary
To reproduce you need to go to the main zyn ui
Then click to add a bank instrument
The bank overview opens

But this is empty!
You can see (red annotate) that is should show the plucked instruments. None is shown
However, if the blue annotated check-box is toggled, then the bank populate.
(PADsynth status is this completely irrelevant btw)
If the bank then is switched to a different bank, it do not populate before a new toggle of the blue-annotate.
A zyn-team bug, no doubt, but it will confuse lmms users, so
Could someone test master, and see if this behaviour also exists, after the newest update?
Test all OS preferely

[musikBear]

also a Master test of #1002 -one more zyn related issue (not lmms!)
if possible?

[tresf]

Confirmed.

1. This has nothing to do with bug 1002.
2. No, we should not document this bug in the wiki. (Instead it should be fixed)
3. Yes, we should verify this exists in latest stable-1.1 since Toby's Zyn merges from upstream (I have not built a windows version yet).

Please retitle the bug to read something more descriptive such as "Zyn - Blank Instrument Bank " and if it's fixed with the next Windows Build please come back and close it out. :)

-Tres

[mikobuntu]

Confirmed bug for me too on linux ubuntu-12.04 32 bit, this has been happening for some time now, longer than the last zasf update anyway. I thought it may have just been my version of QT/FLTK or something but if windows users are also getting this, then it certainly is a bug.
Anyone on a recent linux Distro to see if they get this too?

[tresf]

@musikBear, can you test the version I just built for bug #1002? It has the latest Zyn code and would determine whether or not this is has been fixed with the recent Zyn code updates from upstream.

[tresf]

I tested against the updated version to no avail. Bug filed upstream.
https://sourceforge.net/p/zynaddsubfx/bugs/50/

[musikBear]

@musikBear, can you test the version I just built for bug #1002? It has the latest Zyn code and would determine whether or not this is has been fixed with the recent Zyn code updates from upstream.

Just dl'd it, i will test
topic changed

---

Unfortunately, still 'same' bug with the build#1002 on xp32.
Bug persist (no population), but behavior is a little different. Toggling the PADsynth-state, will still force population, but that also happens, is mouse is clicked anywhere on the blanck form. First the instrument that is directly clicked is shown, and at mouse-release, all is shown. Looks like population actually has taken place, but a screen update is missing - Its the zyn-teams bug!
(But mikobuntu #1002 is fixed and works, other enhancemenst too, due to Tobys upgrade, but not list population -a new feature though: http://snag.gy/mQC1W.jpg - Believe this is the PADsynth-state in individual synths, but a toggle is still needed before population from the list)

---

Edit
Nahh stressing it and :
http://snag.gy/YN3PN.jpg
so not good -OBS its zyn that crashed ! lmms-instance is still ok, and works!

[tresf]

They have the bug in their tracker now. I'll update this bug report if/when they chime in.

[tresf]

http://sourceforge.net/p/zynaddsubfx/bugs/50

The bug report was immediately closed as "out of date" with instructions to upgrade to 2.5.0.

@tobydox How much work to get a 2.5.0 port?

I tried a few workarounds to fix this on our side to no avail. Fluid is quite hard for me to read, but the refreshmainwindow function seems to be fixing this however manually calling it on show() didn't seem to do anything so this should probably be closed as won't fix for now and reopened if still around with 2.5.0?

[fundamental]

I'll warn you before starting the merge. If you have significant differences in the fluid files, then the merge is going to get "Fun" real quick. It was a pretty big hassle to merge in for me (development branch into master) which is the primary reason for why I'd like to avoid dealing with patches pre and post merge. Also, the current state of master does include it's own share of bugs, though the majority of them should be quick and easy to fix (at least for me).

[diizy]

On 07/20/2014 10:05 AM, Tres Finocchiaro wrote:

http://sourceforge.net/p/zynaddsubfx/bugs/50

The bug report was immediately closed as "out of date" with
instructions to upgrade to 2.5.0.

@tobydox https://github.com/tobydox How much work to get a 2.5.0 port?

I tried a few workarounds to fix this on our side to no avail. Fluid
is quite hard for me to read, but the refreshmainwindow function seems
to be fixing this however manually calling it on show() didn't seem to
do anything so this should probably be closed as won't fix for now and
reopened if still around with 2.5.0?

What 2.5.0? 2.4.4 is the latest stable release AFAIK, and we've already
updated to that.

[tresf]

@fundamental, thanks for taking the time to cross-post on our bug report. I was aware were were up to date with latest from the Zyn project. Is there a newer version available?

[fundamental]

@tresf, there is the current git master HEAD which is the result of merging in a long lived branch dubbed the "anti-broken system"(ABS) which effectively rewrote the entire UI<->backend interfacing (which has a large number of other consequences I won't go into (mainly OSC everywhere)).
The 2.4.4 was before this merge and I currently do not intend to produce a 2.4.5 which would involve changes to the 2.4.4 line without the ABS modifications.

As such if there are any bugs which affect only the 2.4.4 code then I'm unlikely to really want to fix those if it is not clear that the git HEAD is also affected which would make a difference for the 2.5.0 release.

I don't know if you would want to deal with the current git HEAD's status though as there are certainly bugs there which need to be fixed.

[fundamental]

http://fundamental-code.com/tmp/zyn-git.png might clarify things on how there is such a big difference even though 2.4.4 was just released.

[tresf]

OK. Thanks for clarification.

Well this is a very minor bug, but our software is downloaded 8,000/week so this bug will remain unfixed and will ultimately make it out into the wild with the 1.1.x series.

There isn't a whole lot of expertise active on our tracker in terms of Fluid GUI knowledge/support so fixing this is a bit more difficult from our angle than some of the CPP bugs we encounter but if we can provide a small fix then we do try to target upstream when possible.

In the case of this specific bug, it is quite apparent that a refresh issue is happening (which I understand from othet regressions I've encountered with Fluid, can crop up as a consequence of certain changes/improvements in Fluid #759 ) so I was truly hoping this to be a one-liner.

That said, our users will still be perfectly fine with the OP's recommended workaround and we can even accommodate via the documentation as previously suggested.

Thanks again for the time on this as well as other matters (such as previous help with the NTK stuff). It's fantastic to know this synth is further improving.

[musikBear]

The click 'hack' on gui does not work for ubuntu-users
https://www.youtube.com/watch?v=foUqtb725JE
look at the comments for this MTTC, apearently this bug is more nasty, than already accessed, If it can be confirmed that ubuntu cant use the gui-hack, zasfx usage is seriously limited for all ubuntu-users
-reopen? -But what can be done to this on the lmms 'side' - new upgrade of zasfx?

[tresf]

-reopen

This bug is open. The closed sign above is for a different bug that had very similar symptoms.

We didn't write Zyn and upstream didn't help when we asked, so if you'd like to look into it, please do.

[fundamental]

@musikBear That looks like a separate issue of incorrect redraw behavior. I've heard of this issue cropping up on both windows and ubuntu, but I have never been able to replicate it on any of my systems nor do I recall anyone being able to report said issue when they had compiled from vanilla installations of the dependencies. Is ubuntu modifying fltk before building against it?

[softrabbit]

I've played around a bit with the UI code for this (BankUI.fl) and so far:

• refreshmainwindow() does get called when it's supposed to. And it does call the buttons refresh() methods as it should.
• calling bankuiwindow->redraw() at the end of refreshmainwindow() makes the instrument bank listing stay empty in all circumstances, the instrument names do appear briefly when clicked.

I'm only guessing here so far, but could it be that all those instrument buttons are somehow being ignored by the bankuiwindow? Like they would have to be connected to it in some way for redrawing to work as intended?

(Ubuntu 14.04, FLTK 1.3.1)

[fundamental]

The only way that that should invoke inconsistent behavior with fltk is if the widgets don't receive the correct parent and based on my understanding and rereading of the 2.4.4 code this is not the case.
So, I don't know what would be causing the issue shown in the video.

[tresf]

Similar to #759

[falkTX]

FYI I've been toying a bit with LMMS zyn using NTK instead of FLTK and this issue is also present there.

One thing I noticed is that the initial choice of beginner vs advanced Zyn UI is not remembered, so there might be some config file conflicts.

[musikBear]

FYI in the vst version of zyn they have added a new button "Update Banks"
(This vst version btw also have fixed the crash when instruments based on AbSine (and one more i cant remember.. ) wave-shape is opend
I hoped i could use this feature, to manage that problem, but the VST-saved zyn-instruments, reverts to default when loaded in lmms)

---

uh in case someone wonder - no connection between lmms-vst-gui and zyn-vst-dials exists, they are all unconnected, and unresponsive

[tresf]

(This vst version btw also have fixed the crash when instruments based on AbSine (and one more i cant remember.. ) wave-shape is opend

Unlikely. It's more likely that they use a different toolchain to build their binaries which is compatible with XP. We aren't going to change our toolchain for this bug so please let this specific (XP-only-crash you are referring to-bug) bug rest.

the VST-saved zyn-instruments, reverts to default when loaded in lmms)

Why use the VST version of Zyn when we have it native already? Upgrade your OS please.

uh in case someone wonder - no connection between lmms-vst-gui and zyn-vst-dials exists, they are all unconnected, and unresponsive

Again, please use the built-in version. Features, bugs or otherwise in the VST version do nothing to help this bug report.

[Sti2nd]

One thing I noticed is that the initial choice of beginner vs advanced Zyn UI is not remembered

I have experienced this, one time... Can not reproduce, Zyn remembers in 1.1.0.

[Gps2010]

I just stumbled on this bug too, with my self compiled lmms 1.1.2 on openSUSE 64 bit.

Unchecking, checking that box works a bit. Should I try to ask about this on soundforce, or am I the only one having this issue?

guus@linux-ab3o:~/lmms2/lmms/lmms2/bin> ./lmms
Notice: could not set realtime priority.
VST sync support disabled in your configuration
(When I load zynaddsubFX )
QtXmlWrapper::loadXMLfile(): empty data
RemotePluginClient::shmget: No such file or directory
QtXmlWrapper::loadXMLfile(): empty data
Starting Audio: NULL
Audio Started
Starting MIDI: NULL
MIDI Started

Edit: I just found out I am still registered to sourcedforge, but can't reply, prob because the bug is closed?

[Sti2nd]

You mean Zyn on Sourceforge???

[ryukusu]

I don't know maybe someone wrote that before me.
Looks like there is some kind of overlay for zynaddsubfx if you launch it from lmms.
I've compared standalone zynaddsubfx and zynaddsubfx launched from lmms.
It affects not only banks but also some another UI elements. I've also found that you can rebrush zynaddsubfx, but it doesn't help to deal with banks.

Also there is some kind workaround to see instruments by one. If you right-click on the instrument you will be able to rename it and thus you will see it's name. It is not convenient.
Is there some another hack to edit QT-applications located in RAM or I have to use fluid, edit sources and compile from sources?

[tresf]

Looks like there is some kind of overlay for zynaddsubfx if you launch it from lmms.

What you are looking at is the NTK themed version of Zyn, LMMS is bundled with the FLTK themed version of Zyn. This is a compile-time option.

That said, I'm glad to see the stand-alone has the same bug, but unless you are on version 2.5, it won't be addressed because the code base has undergone significant changes and the Zyn team hasn't shown a whole lot of interest in working on the 2.4 bugs.

Is there some another hack to edit QT-applications located in RAM or I have to use fluid, edit sources and compile from sources?

I don't know the answer to this, but historically I've edited the fluid sources for what you are describing. I'm not entirely sure what that has to do with QT though if you are running the stand-alone version, AFAIK, the QT build isn't officially supported yet by the Zyn team.

If you're looking to help fix/debug this on LMMS, time is probably better spent working with Dave on the 2.5 upgrade and seeing if it still exists there.

[curlymorphic]

@ryukusu I have taken some screen shots of the new zasf 2.5 imported into lmms. Are the issus mentioned addressed?

[tresf]

... ah... a picture is worth 1,000 words. Thanks @curlymorphic Dave!

[ryukusu]

@tresf
looks like you misunderstood. left is the stand alone zynaddsubfx. it has no such bug. I just mentioned that on the standalone it has no overlay while lmms version (right side) has some kind of overlay.

@curlymorphic should I downgrade then to previous lmms version, change sources and compile from sources or wait for next release?

[tresf]

looks like you misunderstood.

some kind of overlay for zynaddsubfx if you launch it from lmms.

What is misunderstood? You have a screenshot NTK Zyn and we don't use NTK. If someone understands your point, please translate.

P.S. The lime-green screenshots make your screenshots quite distracting to look at. ;)

[falkTX]

@tresf I think he's using the kxstudio packages, which uses NTK.

[tresf]

@falkTX, Do you have a custom build script?

[falkTX]

Yes, it's some changes to cmake and also some quick build-script to make things work.
I didn't manage to do everything via cmake yet, otherwise I'd have sent in a patch.

Anyway, yeah the zynaddsubfx in the lmms kxstudio packages uses ntk.
It has the same bug as the regular fltk build.

[tresf]

Anyway, yeah the zynaddsubfx in the lmms kxstudio packages uses ntk.
It has the same bug as the regular fltk build.

Thanks and apologies to @ryukusu for the misunderstanding.

[ryukusu]

Thank you for clarifications. 👍
I knew that I shouldn't use KXStudio, but I was lazy to get the sources.
OK I will install lmms from sources and tell you if anything goes wrong. :)

[falkTX]

There's nothing wrong with the kxstudio packages.
In fact because it uses NTK zyn will look a bit nicer than usual.

[ryukusu]

I agree, that it looks more like flstudio. It's OK for me.
But when I decide to remove it and install fluidsynth-dev to compile from sources I've encountered dependency problem(with held packages). I will figure it out but looks like i'd better avoid using custom repos if I can compile from sources and it is not something critical for system.

[falkTX]

the kxstudio's lmms package purposefully conflicts with libfluidsynth-dev so it always uses fluidsynth-static instead.
the reason to use static libs is that kxstudio only builds once, and for the oldest available distro supported (debian 6) the libfluidsynth it has is too old.
(we could build against a new libfluidsynth version but then it wouldn't work on debian 6 or ubuntu 12.04)
take a look at debian/control and rules files to understand what it is doing.

anyway, this has nothing to do with lmms.
sorry for being off-topic, but I had to clear that little info.

[haakonn]

Still reproducible on LMMS 1.1.3 (KXStudio packages) on Ubuntu 15.4. Very annoying.

[tresf]

Still reproducible on LMMS 1.1.3 (KXStudio packages) on Ubuntu 15.4. Very annoying.

Agreed, but this isn't our bug and upstream wants us to upgrade to 2.5 prior to it being fixed. I'm closing this out as not-our-bug. We can re-investigate if and when we move to 2.5. Sorry, but for now, we'll just have to continue living with this one.

[etsnyman]

Almost a year later, and this is still a problem. Workaround does nothing.

[tresf]

Almost a year later, and this is still a problem. Workaround does nothing.

Sorry, but for now, we'll just have to continue living with this one.

[musikBear]

Workaround does nothing.

That depends! -IF (!) you can use VST then you can use the VST stand alone for everything related to editing, and your new presets will after import as zasfx presets, work perfectly in lmms. You can even work with the VST in VST-host side by side with lmms. OK that is NOT a fix, but it is a work-a-round that does work!
For reference:
https://www.youtube.com/watch?v=hrrl3OiiJvM

[echuber2]

Is this fixed in 1.2.0-RC2? Looks like I'm late to the party but this is still a pretty glaring issue with the KXStudio version.

[tresf]

Is this fixed in 1.2.0-RC2?

No, and it won't be as the version we bundle is too old for upstream to maintain, sorry.

I've spent a considerable amount of time with FLTK and these UI problems and could never figure out what was causing it. I expect Zyn 2.5 (or perhaps a future 3.0) to happen long before this bug is fixed. If you want to hack at it, please feel free. The best notes are documented here: #1001 (comment) (Edit: fixed link)

[echuber2]

@tresf Did you mean to link directly to this same thread? I might take a look at the code if time allows (I wish...)

[tresf]

@echuber2 yes, but the link was wrong. Mean to link to the code comment. Here it is: #1001 (comment)