Closed markusthegeek closed 10 years ago
asb2m10
commented
10 years ago You can already save the current program but the complete 32 patches are not saved within VST host. As soon has the packProgram is done, this feature will also automatically work. This is planned in the next milestone (within the next weeks).
markusthegeek
commented
10 years ago Right, I discovered the latest patch recall after writing my original comment. Looking forward to the next milestone then!
Ah, I guess you have 155 parameters in memory and need to get them back into the condensed 128 byte format.
Sent from my iPad
On Jan 14, 2014, at 4:06 PM, Pascal Gauthier notifications@github.com wrote:
You can already save the current program but the complete 32 patches are not saved within VST host. As soon has the packProgram is done, this feature will also automatically work. This is planned in the next milestone (within the next weeks).
\ Reply to this email directly or view it on GitHub.
asb2m10
commented
10 years ago Hi Markus,
I've added the complete plugin storage state. It now saves the 32 programs and the current program. Let me know if it works on your side since VST state saving can be tricky between host.
Thanks for you comments ! Regards, Pascal.
markusthegeek
commented
10 years ago Hi Pascal,
Excellent work, I checked out an early version last weekend. Let me give it a more thorough try tomorrow. Really love your idea with the cartridges :-)
Couple of things I saw:
Gruss, Markus
Sent from my iPad
On Jan 19, 2014, at 9:39 PM, Pascal Gauthier notifications@github.com wrote:
Hi Markus,
I've added the complete plugin storage state. It now saves the 32 programs and the current program. Let me know if it works on your side since VST state saving can be tricky between host.
Thanks for you comments ! Regards, Pascal.
\ Reply to this email directly or view it on GitHub.
asb2m10
commented
10 years ago Hi Markus,
Thanks for the update.
Thanks again Pascal.
markusthegeek
commented
10 years ago Hi Pascal,
wow, you beat me to it ;-)
here the latest test results based on your fixes from today:
1 . I did try to modify the zip file but that did not change anything the last time I tested, I removed your files and replaced them with the original builtin_XX.syx files from SynprezFM. So I assumed that you are loading from a big binary blob in BindayData.cpp instead. I assume that in the blob the order is off (it still is btw if you compare to the page below). builtin_01 is in SynprezFM_01, builtin_02 is in SynprezFM_12, builtin_03 is in SynprezFM_23 etc.
http://www.synprez.com/SynprezFM/patchtable.html
Let me know if I should retry to replace files in the zip file and recompile and if I need to do anything special in addition. If the zip works, this would be a dream indeed and a clever way to add your own banks!
2 . Recall of both cartridge and program is working great now! However, when recalling, program 32 is always corrupt in patch name and sound. Do you see this as well?
3 . I am still compiling as 32bit but using Reaper 64bit with the VST bridge. I am using your original cartridge SynprezFM_23 aka builtin_03.syx; get frequent crashes when I start from program 1 (FLEXI 4) and go up using program changes and play a few notes with each program, usually happens within the first 5 programs, not always repro. Never have crashes e.g. with Dexed_01 or SynprezFM_01. Happens in many cases, might be related to using PC to change programs.
4 . Names look great now!
new: 5 . Both Save and Store seem to work great; maybe restrict the length of the Name field to 10 chars? Nice to have for later: store into a slot of any saved file, that way you can create your own "best of" cartridge, The DX7II allowed that on the built-in floppy drive, so I never needed a computer with a bankloader ;-)
new: 6 . Program Change position is wrong if you start at program 01 increase to program 10 and then select program 01 from the GUI. PC is still at 10 internally. PC can also over-count if you click up after program 32! You have to then go down the same number of times plus one to go back to program 31 etc. Does not under-count, good.
new: 7 . Some patches sound distorted, I believe this is because the original DX7 only went to 100 not 127 velocity. I could not find a key velocity sensitivity parameter (0-7). Maybe a global velocity filter would be possible that would keep velocity at max 100 with an on/off option for this filter?
new: 8 . When VST window is pinned to always be in front, the drop-down menus are drawn behind that window.
Looking forward the next version! Let me know if you want me to test other stuff like algo images (some seem off) or automation of controls via sysex (could only see data being sent out but not automate using various hosts not just Reaper).
gruss, Markus
asb2m10
commented
10 years ago Hi Markus...
Oups, that's a lot of issues
If you change the zip file, you need Introducer that comes with JUCE to regenerate the BinaryData.cpp that copies the content into this file.
_2. Yes, program 32 is corrupted on my side upon VST recall. Let me check this....
_3. I'm unable to reproduce this, but with Reaper 32bit (OS X/Win). Reaper bridge doesn't seems to update VST status, I'll dig this a little bit more deeper with the 64bit version.
_5. Yes, it is planned; I just need more experience with JUCE dialogs to make something that fits with the rest.
_6. When you say you increase; is it by midi ? GUI ? I'm curious on how you go beyond program 32.
_7. Yes, I saw that too. Maybe normalizing to 100 as a velocity is an option. I'll check what I can do.
_8. This is a Reaper 64 bridge display bug. I don't have the problem with Reaper Win 32bit.... probably fixed in a new version of JUCE. I'll check to update JUCE version.
Regards, Pascal.
asb2m10
commented
10 years ago Hi Markus,
Ok, issue 1 and 2 is fixed.
Issue 3, (6) and 8 seems to be fixed with a native 64-bit build. It didn't crash on my side with the 32-bit bridge but the program names didn't update and sometimes no sound would come out of the plugin. I've added x64 to the VS solution, now works like the 32bit version. Please try it out on your side to see if it resolve the PC.
As for issue 7, looking at the code android music synthesizer, the velocity seems to be within the same range as midi (127). The variable normalizeDxVelocity as been added to normalize velocity value to 100; but it is not yet enabled by default.
Yes, the next version is coming soon, I'll be looking forward to add a store program into another sysex file. If you can make some parameter output test, that would be great...
Again, thanks for your comments and don't hesitate if you see anything strange. Regards, Pascal.
markusthegeek
commented
10 years ago Hi Pascal,
sorry about putting all these issues into one report, maybe I should open additional reports in the future.
again, you have done great work. I am now compiling for 64-bit and so far things look really good!
issue 1: excellent, confirmed fixed now. order of cartridges is now like in the original. I have not yet re-tried the zip method using Introjucer. maybe it is also enough to load and recall an external SYX file for this use case.
issue 2: yup, program 32 recall is not fixes as well!
issue 3: seems to be fixed with the 64-bit version indeed. at least, it happens less often upon further testing, not always crashing at the same patches either. let me watch for any kind of pattern. you have to send program changes via MIDI in order to get to this crash.
issue 4: closed
issue 5: great if you can get this in but no rush. happy to test when ready.
issue 6: believe this is by design and my problem ;-) my keyboard sends PC numbers and not relative up and down messages. so when I have PC 3 and select program 10 via GUI, keyboard will go up to number 4 and not number 11. this is not fixable as far as I can see. only thing you can do is the following: when I send a PC > 31 you could wrap around and start back at program 1, same for every 32 patches up. this is because you support 32 programs while MIDI supports 128 programs. just an idea...
issue 7: sounds good, let me know when you want me to test this.
issue 8: works fine if the GUI is drawn within the VST FX window. if you have the GUI in a floating windows it still works unless this window is pinned. not a biggy, just let me know when you updated to a newer JUCE version for other reasons, then I can re-test.
so I believe watching for the crashes in issue 3 is the only critical issue left from the list above.
gruss, Markus
Hi Pascal,
would it be possible to set and get the 32 currently loaded patches from the VST chunk?
I believe this should be possible in the way you load the binary SYX block when starting. Basically you save the block into the VST chunk when unloading the plugin and recall it back when loading the plugin the next time. If you do not find a VST chunk, you fall back to the current solution. When the user imports a SYX file during a session, that block is saved and recalled.
That way, I can have different projects with different patch banks loaded. This is useful when you use a headless system were you can only use program changes to switch patches and not load new banks on the fly.
http://www.juce.com/api/classVSTPluginFormat.html#a666e9aa327d8daaafa05b6b899166ff9
gruss, Markus