Skip to content
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

Open
harryhaaren opened this issue Mar 7, 2016 · 18 comments
Open

Real-World DAW Testing #42

harryhaaren opened this issue Mar 7, 2016 · 18 comments

Comments

@harryhaaren
Copy link
Member

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

@harryhaaren harryhaaren added this to the 2.0 Release milestone Mar 7, 2016
@harryhaaren
Copy link
Member Author

@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

@MrThraz
Copy link

MrThraz commented Mar 7, 2016

I’d love to help, I’ll install it again and put it thought its paces.

@harryhaaren
Copy link
Member Author

@MrThraz , great, awesome even!

Any feedback, just post a new issue, and link it from here so other testers have some visibility.

I've found one issue:
#43

Thats all for now! -Harry

@harryhaaren
Copy link
Member Author

@prokoudine, @naught101, @jkroll20, @nicopan,

At one point, a long time ago (2014!) you guys suggested features in the Fabla 2.0 Wishlist thread:
openAVproductions/openAV-Fabla#36

If any of you have an interest in testing / feedback etc, the next few weeks is a good time.
No pressure, just a note! Cheers, -Harry

@naught101
Copy link

I'll see what I can do.

@harryhaaren
Copy link
Member Author

Issue with Ardour4 reported by @sandsound:
#44

@harryhaaren
Copy link
Member Author

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:
https://sourceforge.net/p/qtractor/tickets/197/

@rncbc
Copy link

rncbc commented Mar 8, 2016

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 ?
i'll have to investigate that sooner as possible.

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:

Fabla2::Save() Error: make_path not available! SAVE DID NOT COMPLETE!

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.

@harryhaaren
Copy link
Member Author

Hi @rncbc, thanks for joining in here, I'll reply in a list:

  • LV2 presets saved in QTractor will not be usable in other hosts. How much you care about this is debatable, but it is certainly a nice feature for users who do live music (using Jalv for example) and studio work with QTractor. If you are interested in a feature-request, I'll file on on SF.net.
  • Fabla1 does not work properly here - and never has. I'm not sure if I'm doing something wrong, but when I close and reload QTractor no sounds come out.
  • LV2 make_path is essential - no preset will load if you don't provide a method for the plugin to retrieve path to the samples:

For a good workflow with plugins that use files, make_path is essential.

@rncbc
Copy link

rncbc commented Mar 9, 2016

On 03/09/2016 06:55 PM, Harry van Haaren wrote:

Hi @rncbc https://github.com/rncbc, thanks for joining in here, I'll
reply in a list:

  • LV2 presets saved in QTractor will not be usable in other hosts. How
    much you care about this is debatable, but it is certainly a nice
    feature for users who do live music (using Jalv for example) and
    studio work with QTractor. If you are interested in a
    feature-request, I'll file on on SF.net.

we can certainly look into this trouble that at first glance seems to
blame on using lv2_state_map_path (abstract_path, absolute_path) locked
in to a particular session directory.

[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.

  • Fabla1 does not work properly here - and never has. I'm not sure if
    I'm doing something wrong, but when I close and reload QTractor no
    sounds come out.

might not work properly, as you say (i didn't actually test the core
functions though) but the lv2_state_save() and lv2_state_restore() do
get called alright, at least here :)

  • LV2 make_path is essential - no preset will load if you don't
    provide a method for the plugin to retrieve path to the samples:
    o Please see example code here:
    http://lv2plug.in/ns/ext/state/#makePath
    o Returning the qtractor sample path "directory" as a string is enough

For a good workflow with plugins that use files, |make_path| is essential.

no, it is not.

map_path (http://lv2plug.in/ns/ext/state/#mapPath) probably might but
make_path (http://lv2plug.in/ns/ext/state/#makePath) certainly is not
that essential :)

either should be optional anyway. qtractor does support map_path
(absolute_path, abstract_path) which are the case for the relative paths
you mention earlier.

you (your plugins, i mean) should have a workaround for the lack of the
make_path extension, for which qtractor won't support anytime soon.

i'd suggest fallback to POD, as a string, or whatever serialized data
type you think is best, but not in an self-created external file contents.

byee

rncbc aka. Rui Nuno Capela

@rncbc
Copy link

rncbc commented Mar 10, 2016

there's news today on the git head master front aka. qtractor v0.7.4.31+
http://sourceforge.net/p/qtractor/code/ci/18cefa
rncbc/qtractor@18cefa4

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 :)

@rncbc
Copy link

rncbc commented Mar 10, 2016

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():

// strip the file:// from the start
path = path.substr( 7 );

(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?
cheers

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? ;)

@kroll-j
Copy link

kroll-j commented Mar 12, 2016

Noticed 2 things so far:

  • I saved a Carla patch with Fabla2, and after loading it, Fabla2's state was not restored. No samples loaded.
  • When I have the Sequencer View open in Fabla2 in Carla, something eats about 90% CPU time of one core. This stops when I switch to another view.

@georgkrause
Copy link

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

@harryhaaren
Copy link
Member Author

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

@georgkrause
Copy link

@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 ;)

@simonvanderveldt
Copy link
Contributor

@harryhaaren Did anything happen with the points made by @rncbc here #42 (comment)?

@harryhaaren
Copy link
Member Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants