-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Real-World DAW Testing #42
Comments
@MrThraz, you've made the mistake of posting on the "Fabla1 presets -> Fabla2" bug, so I'll ping you here too in case you are interested and have time to help out. Again - no pressure! Cheers, -Harry |
I’d love to help, I’ll install it again and put it thought its paces. |
@prokoudine, @naught101, @jkroll20, @nicopan, At one point, a long time ago (2014!) you guys suggested features in the Fabla 2.0 Wishlist thread: If any of you have an interest in testing / feedback etc, the next few weeks is a good time. |
I'll see what I can do. |
Issue with Ardour4 reported by @sandsound: |
QTractor testing proved unsuccessful: no Load() or save() called - same issue with Fabla1, so not suspecting the Fabla2 implementation. Also, F2 works fine in Jalv, so it shouldn't be F2's fault. Filed a ticket on QTractor bug tracker: |
re. Qtractor ticket #197 re. SAVE: yes file-paths are saved relative to (current) session directory; that's true and working as ever was; working as designed; also, if you save a session to .qtz suffix all file-paths get bundled into the zip/archive, being this the qtractor's own way of session portability either across the file-system hierarchy or even across system machines. re. LOAD: qtractor uses and should call LV2_State_Interface::restore() alright. for whatever some reason it seems not being invoqued on Fabla2 ? ps. it all seems to work on Fabla1 (lv2_state_save/restore()) ... build Sep 6 2015. testing with a freshly built Fabla2 (todays git head) I get this horror message when saving a session:
the issue might be related to lv2_state_make_path interface feature for which qtractor does NOT currently support--maybe never--although there's some code for that it has been disabled as broken as FUBAR :) please don't rely on it--you will get undefined results if you enable the feature on qtractor. sorry. |
Hi @rncbc, thanks for joining in here, I'll reply in a list:
For a good workflow with plugins that use files, |
On 03/09/2016 06:55 PM, Harry van Haaren wrote:
we can certainly look into this trouble that at first glance seems to [ERRATA] qtractor lv2_state_map_path interface always resolves to absolute_path(), both ways, when saving lv2_presets. so that portability of the file-paths stored in a lv2_state_preset might not be an issue after all.
might not work properly, as you say (i didn't actually test the core
no, it is not. map_path (http://lv2plug.in/ns/ext/state/#mapPath) probably might but either should be optional anyway. qtractor does support map_path you (your plugins, i mean) should have a workaround for the lack of the i'd suggest fallback to POD, as a string, or whatever serialized data byeerncbc aka. Rui Nuno Capela |
there's news today on the git head master front aka. qtractor v0.7.4.31+ a) it affects the relative/absolute file-path dilemma on lv2 presets saved within qtractor--now all file-paths should get mapped relative to the lv2 preset directory/bundle and not always absolute-path as before. b) later today i'll try to revive the lv2_state_files_make_path interface, which is disabled since its inception (3y+ ago) due to concerns that might not be applicable nowadays. let's try and see if the FUBAR turns into a SNAFU :) |
while doing the lv2 make_path revival stuff (mentioned in last post), i come to look into Fabla2 source code and found this WTF in fabla2_restore():
(cf. https://github.com/harryhaaren/openAV-Fabla2/blob/master/src/lv2_state.cxx#L359) wouldn't it better to check and compare whether the first 7 characters are actually "file://" before stripping them off? :) one other thing, this time even more IMPORTANT for getting this make_path revival a reality in qtractor: -- shouldn't you convert the brand new make_path() supplied file-paths through map_path::abstract_path() BEFORE you store the full state (a JSON string in your case)? and please do this AFTER the actual files are created and existing on the file-system. i believe this is clearly stated on the docs (cf. http://lv2plug.in/ns/ext/state/#makePath). failing to do so will prevent qtractor to bundle the new files in a session archive/zip file (.qtz) and thus certainly miss the files on next load and worse, get them lost into the void later on. there's yet another problem i see after looking at the Fabla2 lv2_state save code: you seem to copy/create new sample files if their base-name already exists in the save (session) directory, by incrementing a numerical suffix. at first glance i find this overkill leading to a lot of redundant and replicated files, piling up on the save directory, whenever one poor guy/gal hits save to current session or a preset. [EDIT] this later question is one kind of a catch-22 i guess, and now it gets bounced to you: why on earth do you copy or replicate the sample files anyway? isn't that supposed host's business? why isn't that simpler to store the (originally) user supplied file path, get it through map_path::abstract_path() and then, yes, store the result path (the relative/abstract path there returned) on your JSON string? by just following this rule it simply gets to no reason why you're making use of make_path whatsoever--you're NOT creating any files under plugin's context anyhow. so let's ask this again: why is it "essential" to you (or any plugin author for that matter) ? am i missing or rather overlooking anything? ps. you probably know that if you get rid of that make_path condition, things will just start to work right on qtractor, both newer and older releases, don't you? ;) |
Noticed 2 things so far:
|
loaded fabla2 in ardour today and it was a mess, i think using fabla2 in ardour isnt a good solution because of the many, only numbered outputs. would be cool if the outputs could have names like the jackports when loaded in another plugin host... dont know if possible |
There's an easy mis-understanding to make with Fabla2's audio outputs, and I agree that without proper documentation it looks a mess. In short, its the best feature Fabla2 has (IMO) and its very hard to explain why this is such a cool feature... This post (from quite a while ago) explains the intended workflow: openAVproductions/openAV-Fabla#37 (comment) I should try to document the intended workflow more clearly - I'll put this on the TODO. Thanks for the input, -Harry |
@harryhaaren sorry for dont answering. i understand the workflow and its cool! but in ardour, the outputs are not named, so one needs to guess which is what. this is the thing i reported here ;) |
@harryhaaren Did anything happen with the points made by @rncbc here #42 (comment)? |
@simonvanderveldt ; short answer: no. I still don't fully understand the proper method that one is "supposed to" use the LV2 make_path etc extensions. Admittedly I've not spent much time investigating it - restoring presets works on Jalv, which is the only host that I test/support "officially" (see here http://openavproductions.com/getting-started/#launching ) IIRC, I tested removing the make_path condition makes it work in QTractor but break in other hosts.. so that's not a solution. |
Hi @ViktorNova,
At this point in time, I am not aware of any bug that will cause Fabla2 to crash. If you wish to help in alpha testing of Fabla2, the next weeks would be a suitable time :)
No pressure if you're busy!
Thanks, -Harry
The text was updated successfully, but these errors were encountered: