Flexi sample not saving in host session?
I've tried searching but can't find anything on this.
I'm loading one of my own samples into the Flexi Sampler in the AU version in AUM and Loopy Pro. I save and then re-open the session in the host. The Flexi instance is empty.
This is way to obvious to be a bug, no? What am I doing wrong?
Comments
@number37 @giku
Confirmed. I just tried loading one of my samples, saved within the Drambo AU, as well as the AUM session, and upon return, Flexi was in its blank state just like you mention.
Edit: The sample is saved in standalone however.
EDIT #2: Hey I just tried saving within the AU, and turning on “save with samples” and it now works as expected.
Thanks for checking. 👍
I would expect that to work since you’re actually saving the Drambo project in Drambo. But you shouldn’t have to save the Drambo project. The host state save should save everything, returning you to where you left off whether or not you saved anything in Drambo.
That’s a key advantage of AUv3. Imagine if we had to save every preset in every plugin in every project.
@number37
True, though I guess a special case could be made for AuV3 apps that also act as hosts?
Drambo and Loopy Pro are both part of a very few that can do this.
True, though I guess a special case could be made for AuV3 apps that also act as hosts?
Not in my opinion. If an AUv3 version is offered then it should be a true AUv3 version. But now that I know about it I just need to avoid using samplers in Drambo AUv3 projects. (I mainly use Drambo inside Loopy, and otherwise love it for that use case.)
miRack and Loopy Pro are two dual-role hosts that do save their full state in the plugin version.
Anyway ... movin' on. I'm not here to stir up trouble. I just thought I'd raise the issue in case it's a bug rather than a design decision. Thanks again for testing / confirming.
@number37 @Intrepolicious weird, I just tried the same and the sample is saved just fine, either by loading it from my own or sampling. I didn’t save the Drambo project in the plugin, just the AUM session. Could it be some setting?
I can replicate this in AUM by dragging a sample from somewhere else into Flexi inside a Drambo AUv3. And I agree that the dropped sample should be saved with the host project. That's the point of total recall.
Maybe something like a "dropped sample folder" in Drambo's file system would make sense, although strictly speaking, IMO it could be a temporary buffer to be saved with the host project.
I didn't load my samples with drag. It was through the standard Drambo dialog.
I can’t replicate this in any way with all three plugin types (instrument, effect, MIDI effect) and all three ways of loading a sound into flexi (record, load, drag-and-drop). This is all on my phone so I’ll try on my iPad next.
App Store version or Beta?
App Store
I tried on my iPad now (App Store version as well; I'm not on the beta) and everything seems to work as expected too.
Just chiming in here- I have also experienced this issue on the App Store version on iPad. Steps to reproduce:
As reported above,if I add step 4A “in the Drambo instance, save as the Drambo project with the save with samples toggle on”, the sample correctly persists when closing the logic project.
I have the same issue with loopy pro:
@superbonbon I just tried with Loopy Pro as well, and it also works for me. I don't know what is making it behave differently for me (and I do agree with others that this is the correct behavior).
For complete context, I tested on an iPad Pro M1 (11") and on an iPhone 13.
What iOS / iPadOS version @NoiseFloored ? (In case maybe that makes a difference. )
iOS/iPadOS 18, but I'm pretty sure it worked the same on 17
Upgrading to iOS 18 didn’t fix this for me, but unchecking the “public filesystem” toggle in settings/filesystem did fix it.
Ah, nice, this should be a good lead. I have the option enabled but there maybe there are other permission issues.
You're right! Turning that off does fix it for me.
It's disabling that option that fixes it - at least for me.
@number37 yep I got that, I'm just saying that everything works for me regardless of that setting, so there must be something else that we haven't isolated. Anyway, I'm glad you have a workaround!