Slow behaviour

[Baeka]

Hi.

I have created a project where I use loops created by dragging the audio into the MUlab. This makes the project slow and if I click on parts etc. it takes several seconds to get any "answer".

My computer is brand new so I have no shortage of cpu or anything like that.

??? - says baeka.

[MuTools]

Can you please post/email a screenshot of your composition so i have an idea of its structure/complexity. Thanks.

By the way: Are you on OSX or Windows?

[Baeka]

Hi. Thanxx for the answer. I have mailed a picture to your email.
Thanks again.

[MuTools]

Well received, thanks.

To be honnest i thought it was going to be such situation i.e. a composition with many (hundreds) of little audio parts.

MU.LAB is not (yet?) optimized for this kind of composition.

If you want to use audio loops, it's better to use them as a sample, not as a little audio part.

Maybe it woud be better that when one drops an audio file onto the composer, and it's a 'little' audio file (e.g. less than 10 secs), then MU.LAB could import it as a sample instead of an audio file.

Audio file parts are rather meant to stream long audiofiles from disk.

Hope i explain well, else let me know.

[Baeka]

Hi and thanxx for the quick answer. I suspected it might be something like that. Then I will rearrange the project.
Respect

[MuTools]

I've been thinking more about this.

I think it would indeed be a good thing if short audio files that are dropped onto the composer are loaded as samples instead of audio parts. I see no reason why not. Anyone objections?

[robenestobenz]

I've been thinking more about this.

I think it would indeed be a good thing if short audio files that are dropped onto the composer are loaded as samples instead of audio parts. I see no reason why not. Anyone objections?

And would this then create a new track with a MIDI note at the drag point, as well as setting up a sampler? My workflow involves dragging audio files straight in quite often, for some reason.

[MuTools]

Yes, my initial thought was sequence part + note + sampler.
Disadvantage is that we won't see the waveform anymore.
Also splitting and cutting works differently, so i think there are objections. So i won't make wild changes at this point. This needs some more thought.

[cytone]

Just a thought on this. If it's a short audio part then it could be loaded into memory but still be treated as an audio part. Have a cut off point where audio is streamed from disk?

[Juan Mendoza]

Yes, my initial thought was sequence part + note + sampler.
Disadvantage is that we won't see the waveform anymore.
Also splitting and cutting works differently, so i think there are objections. So i won't make wild changes at this point. This needs some more thought.

Based on my experience with Muzys and a similar workflow (ie. audio files threated as samples) i agree that there are some objetions to this method of handling audio files.
The most important for me is that playback is afected, 'cause you need to put the play cursor at the very beguining of the note if you wanna hear the audio part, and it's really anyoning when you're navigating through the project.

I'd seriously think in the advantages vs cons. I'd prefer that you'll find a solution for the "performance problem" so that mulab handles audio files better, rather than implementing this "shortcut" to address the problem.

[Juan Mendoza]

Just a thought on this. If it's a short audio part then it could be loaded into memory but still be treated as an audio part. Have a cut off point where audio is streamed from disk?

+1

[MuTools]

Yes, my initial thought was sequence part + note + sampler.
Disadvantage is that we won't see the waveform anymore.
Also splitting and cutting works differently, so i think there are objections. So i won't make wild changes at this point. This needs some more thought.

Based on my experience with Muzys and a similar workflow (ie. audio files threated as samples) i agree that there are some objetions to this method of handling audio files.
The most important for me is that playback is afected, 'cause you need to put the play cursor at the very beguining of the note if you wanna hear the audio part, and it's really anyoning when you're navigating through the project.

Note we're only talking about short audio files, lets say max 4 bars long, so i don't think the cursor aspect is a prob.

Besides this, using many hundreds of little audio parts in a composition was not really the intention, and the audio part subsystem isn't really written for that, hence the performance penalty. It also takes a lot of RAM that way!
Audio parts are rather meant for disk streaming.

Anyway, feel free to use it as you want.

I'm not sure if i'm going to rewrite the audio part system.
I was rather thinking about a separate type of part, a 'audioloop part' that would incorporate REX, beat slicing, beat stretching etc. But that's one for the longer run. I'll soon post a topic about the next steps.

[Juan Mendoza]

Note we're only talking about short audio files, lets say max 4 bars long.

I know, but even if it's 4 or 2 or 1 bar it's very anyoning, at least for me, real time and perfectly synced playback at any point of a composition is IMO very important when you're making some finetunings at certain points of a composition or a track, and you need to repeat certain parts many times.

Eg, if i have a 4 bar audio loop and i want to do an automation or whatever at bar 4 i need to play the 4 bars each time i want to hear or edit the changes in bar 4.
I find this method in the way of a fast and inspiring workflow.

[MuTools]

Crossed posts - I edited my previous post.

[MuTools]

Note we're only talking about short audio files, lets say max 4 bars long.

I know, but even if it's 4 or 2 or 1 bar it's very anyoning, at least for me, real time and perfectly synced playback at any point of a composition is IMO very important when you're making some finetunings at certain points of a composition or a track, and you need to repeat certain parts many times.

Eg, if i have a 4 bar audio loop and i want to do an automation or whatever at bar 4 i need to play the 4 bars each time i want to hear or edit the changes in bar 4.
I find this method in the way of a fast and inspiring workflow.

But you have the same thing with longer notes and sample loops, there would be no difference to that. Not rejecting your point. But there are limits anyway.