openAV-Luppp
openAV-Luppp copied to clipboard
openAVproductions
Set tempo based on recorded loop
Luppp's workflow seems to be set on recording to the bpm you set. Coming from SooperLooper I am more used to recording a loop first and then the tempo is set from the initial loop and number of 8ths per loop.
This is probably quite a big one so I am interested in your thoughts on adding this alternative workflow.
Its not too difficult a feature to add actually, and its something that is indeed very useful. Thanks for the reminder, its on the TODO here. -Harry
Kasbah: a question for you, what do you want the workflow to be like? A footpedal press to start recording, and press again to stop recording, with the exact time of the footpedal press being the times used?
Since theoretically, any 90bpm song could be concidered 180bpm too, there would most likely be 2 / 3 BPM values that could be valid. In that case, pop up a dialog asking what BPM to select, highlighting the "most-obvious" choice?
Note the BPM issue is more complex in Luppp than SooperLooper, as the loop timestretch logic is more complex to provide fancy features in future..
looping + fx + timestrech with a fixed bpm, is something that is done in puredata or max msp for centuries (lately with dirac ~). In Windows or Max there is a free tool called MOBIUS, it can be used in Linux via Wine, with good results but with a problem to sync with midi jacktime or externally. An interface whose way of working is to set one manually bpm, then play is very poor, even Ableton Live has methods to set starting via master loop, the overall tempo. Using the "looper device". It is important to think about these things from the perspective of a musician. To me it is useless a tool where the master loop track, not sets the tempo. Solve that and still have timestreching functions is not important, it is fundamental.
I am not sure. In my workflow at the moment I am not too concerned about the BPM but rather just that everything is in sync with the first loop. I.e. it is important to me that subsequent records and overdubs are synced with the first loop. At some point I did use the BPM output to drive arpeggios and effects but not at the moment. This is a really specific workflow though and it's probably worth thinking more about what is useful to most. Note that in SL you can also set the cycle length to any loop and then sync to 8ths or cycles or you can also get BPM from Jack-transport or the MIDI input. Not saying that Luppp needs all of this, just some things to think about.
The pop-up, asking you for the number of 8ths (or maybe beats/loop would be a more universally understood term) doesn't sound so bad, if it disappeared after a period of inaction (using the default) and didn't block any other actions even when showing.
I am not sure what effect the time stretching has. SL does have some stretching as well but you can't record over over a stretched loop at the moment. You can change the rate (which changes the pitch too) and record over that and the rate is then relative to rate set at the time of recording. Is the pitch adjustment used for the stretching tied to the BPM? Can it not work on loop length?
@Peterpotamos : thanks for your feedback
Luppp is designed totally from the ground-up for musicians. Belive me when I say this, I've redesigned the Luppp UI several times now, and I'm still improving it regularly. (Checkout todays commit 672429d9165b48fb4dcab7960d637da83796eb1c, which adds BPM estimation of loops, making it much easier to set thier tempo).
You mention needing features like "master loop track setting the tempo", that's cool. I personally don't use such a feature: hence why its not in Luppp right now. With constructive feedback from you and @kasbah, we can get this feature working in Luppp soon.
I'm interested in you "perfect workflow" for such a feature, and I'd appreciate suggestions.
@kasbah : Thanks for the suggestions: Sync modes: Its very difficult to get sync working perfectly: and involves a lot of time-consuming testing. I have thought about JACK / MIDI / Loop / 8th sync, but adding more is not a good expenditure of my time right now.
I hope to streamline the recording process, providing a new way to indicate a "master-loop-length", which would allow you to use the workflow you describe where one specific loop lenght is the basis for the rest. Note that they would all still be synced to the Luppp TimeManager clock behind the scenes, but the interface will show the functionality you're in search of.
If an approximate "tap tempo" has been performed before the recording starts (or during), then Luppp will be able to automatically do loop-lenght detection, because it has some information avaliable: the dialog would only need to be used in cases where the metronome could be totally off, and a drastic change in BPM was intended: eg 174 dnb speed, to a slow 87 bpm hip-hop tune.
Overdubbing is another issue, which is currently not supported yet. It is in planning, and I hope to include it in Luppp 1.1.
I'll look into this issue furthur tomorrow, Cheers -Harry
Hi @Nomys, thanks for your input - I'm not sure if this is going to happen soon I'm afraid. OpenAV is working on some other projects with a higher priority right now (releasing ArtyFX with AVTK UI's, and testing the plugins on the MOD).
I do see the need for a looper that is more musician friendly, and OpenAV does hope to accomodate workflows like yours better in future. Cheers, -Harry
Aww, that's too bad, I will maybe go back to sooperlooper, cause I'm only using live samples and no pre-recorded samples...
Plus it seem to me that the "use as tempo" function is very one sided, cause it's only to use a loop with and unknow tempo. Changing it into a set tempo based on recorded loop, just need to play the unknow tempo loop with an another soft/source, and record it with luppp. More annoying but the function is far more flexible in itself.
Or am I missing something with "use as tempo" ?
@Nomys honestly, nobody is working on this. but we would be happy to see a Pull Request with this feature. ;)
Edit, more verbose: In Luppp there are a lot of feature requests and issues adressing the complex of timing. This is a quite difficult part and there is a lot to think about, to fix, to design propperly. In short: There is a lot of time to spend on this to do it right. We currently have two devs working on luppp, its Harry and myself. We both have other plans at the moment and wont adress this one in the near future. Am I right, @harryhaaren?
Please note, there are also tasks which can be done without being a dev. If you are interested in participating, please let me know or join the IRC #openav@freenode
So it's basically the same answer it already was back in 2015...
Man, i'm currently working on far too much free projects to have any time to contribute to Luppp. I briefly saw @harryhaaren at le Linux Audio Conference last year (in Saint-Étienne) and he told me to come here and complain (or just diggout the topic, I don't remember ;o), so here I am !
I know its frustrating, its the same for me. But I really can't change something about. Luppp has this issue #128. I tried to fix but I am not able to. But until this is fixes we can't implement anything which relies on changing the tempo on the run.
@Nomys Since i got this feature request on LAC a few times and #128 seems to be solved in the near future and this is the oldest feature request we have, i started thinking about this one.
Before i collect some thoughts on this, i need to say the following: I spend a big amount of time on Luppp development in the last weeks to get rid of this annoying bug. Sadly, this totally blocked my brain and i didnt found time to actually make music. This is no problem at all, but when the bug is fixed some day, I will concentrate again on some musical projects. This means, i cannot tell anything about when this feature will be ready for production. Before we can actually implement this, I think we need higher precision BPM-settings. We need to set somethink like "120.65". This might be not that hard, but i didn't looked into this.
Anyway, I think its time to start working on this. Yey! This means, i need your help for thinking about the workflow. What we need is a way to tell Luppp to disable the grid on recording for a specific clip. How do you want to do this? What can you imagine? What do you need. Would be happy about any input about.
In the end, this feature wont make it into the next release, but hopefully in the one after the next :)
\o/\o/\o/\o/\o/
Don't worry, I'm in wait for this since 2015, I can wait 1 or 2 years more now ;o)
I think a sync choice button like in sooperlooper could do the trick for me. This button allows to change the focus of the grid. Since Luppp is mainly about bpm sync, a sync button will be just a choice between "bpm" or "clip". "clip" can have a lot of choices (all clips or just one clip per track made only for this use allowing multiples tempos between tracks), but for starter just have one clip you can record on with the grid disabled, then define the grid at the length of the recording and finally enable the grid for the other loops.
What do you think ?
"clip" can have a lot of choices (all clips or just one clip per track made only for this use allowing multiples tempos between tracks)
The current TimeManager does not allow this, and this is not really the topic of this feature request, is it? This would need some pretty deep changes and is already tracked somewhere else. Lets focus on the feature of setting the tempo after recording something in relation to the recorded clip :)
just have one clip you can record on with the grid disabled, then define the grid at the length of the recording and finally enable the grid for the other loops.
This seems pretty possible. We need a button somewhere to disable the grid. Than record a clip without grid and after this we can use the "Set as tempo"-function for setting the grid again. So we have two steps here:
- Make it possible to disable the BPM-Grid.
- Determine how much beats are in the recorded clip.
After thinking a little about this, I think a simple global "Disable Grid"-Button can cause some problems. It might be better to have a more intergrated workflow. Eg a button which says: Record next clip without grid, determine the BPMs and set tempo.
Maybe this could be also related to #119 somehow. We could set a master clip which can be recorded with or without grid and tempo is aligned to this.
So, i see some problems, i have some ideas, this needs to go into a specific workflow and maybe i also need to do some tests.
@harryhaaren One technical question: Is the event-system fast enough to set the exact start and stop of a clip? So when i press the button on the GUI or the Midi controller, is there any relevant latency until the clip is triggered?
The current TimeManager does not allow this, and this is not really the topic of this feature request, is it? This would need some pretty deep changes and is already tracked somewhere else. Lets focus on the feature of setting the tempo after recording something in relation to the recorded clip :)
I kind of knew this would be a problem :)
This seems pretty possible. We need a button somewhere to disable the grid. Than record a clip without grid and after this we can use the "Set as tempo"-function for setting the grid again. So we have two steps here:
- Make it possible to disable the BPM-Grid.
- Determine how much beats are in the recorded clip. After thinking a little about this, I think a simple global "Disable Grid"-Button can cause some problems. It might be better to have a more intergrated workflow. Eg a button which says: Record next clip without grid, determine the BPMs and set tempo.
Yes !
I think one problem in this will be the second point, cause you can't set a meaningful tempo with only a sample length... You only can have a relative tempo use by the grid but not visible for the user cause confusing.
I don't really get what you mean. We have the length of the recorded clip given in samples. We know the BPM is between 60 and 220 (current limits of luppp). So we have some values which are possible. Others are not. The difficult part is to chose. We cannot really wait for user input (or can we?), since it needs to be applied fast. On the other hand: how bad is it to pick the wrong tempo? It actually applied tempo might be twice or half of the intended one. So things would still fit somehow, but your metronome shows 1/8 or 1/2 instead of 1/4. Can we live with that?
I need to investigate how its done on loading an unknown sample... Let's see. Please try this feature, because this is what we already have and using this as a base would make things easier.
Sorry, I wasn't very clear, this :
It actually applied tempo might be twice or half of the intended one. So things would still fit somehow, but your metronome shows 1/8 or 1/2 instead of 1/4.
Is what I mean by relative tempo, we can totally live with that, but it's just not as precise as 144.8 bpm for exemple...
I need to investigate how its done on loading an unknown sample... Let's see. Please try this feature, because this is what we already have and using this as a base would make things easier.
As I recall, You set a tempo and when you load a sample the grid is just applied to it, if the sample doesn't match the grid, some beats will just be blank.
I will test this week, but I think this is something like this...
Is what I mean by relative tempo, we can totally live with that, but it's just not as precise as 144.8 bpm for exemple...
These are two different topics. Of course, before we can start working on this, we need the possibility to set the BPM more precicely. This means things like 145.35 need to be possible. This is the first step.
Applying the grid can than have the issue that you play something on lets say 60 BPM but Luppp assume its 120 BPM. The question is, if this is a problem or if we want a user decision which would force luppp to wait for it.
Let me know how your testing was.
Applying the grid can than have the issue that you play something on lets say 60 BPM but Luppp assume its 120 BPM. The question is, if this is a problem or if we want a user decision which would force luppp to wait for it.
It is not :)
I didn't have time to test and it will be difficult on the few weeks ahead to find time but I'm still on this...
@Nomys I spend some time on this. I think the workflow will be like that (@harryhaaren maybe you can tell if its okay for you):
- There will be a Button to enter a special Mode.
- In this mode you can record ONE clip which wont be synced to the grid.
- After recording this clip, the normal mode will be active again and the grid is synced to the recorded clip.
This way, all already recorded clips will be stretched to fit into the new tempo (like it is now when you change the tempo).
It seems great !
Is this clip will be a specific clip (in a specific slot) or is it just the first clip recorded after entering the special mode ?
This way, all already recorded clips will be stretched to fit into the new tempo (like it is now when you change the tempo).
So you have tested ? Clips are stretched when the tempo is changed ? That's pretty odd behaviour for me, but doesn't really change anything for my needs...
So you have tested ? Clips are stretched when the tempo is changed ? That's pretty odd behaviour for me, but doesn't really change anything for my needs...
Just run current luppp and change the tempo and you will see the length of the clip is changed to fit again to the new tempo. Why is this odd?
It is not a specific clip, you decide which one it is by recording there.
This has one problem: If you record a new clip this way, the wrong BPM-Choice will make your already recorded clips be played back on the wrong speed.
And in this special mode it is only possible to record one clip and not multiple clips with different lengtth at the same time, @georgkrause?
Well, this special mode gets deactivated after you recorded one clip. Recording of multiple clips are not possible in this mode. This is the easiest way, if we want to allow this we need to think about:
- How to decide which of the recorded clips sets the tempo?
- Are the others synced to grid?
- How should they be played back? starting at the same time? Calculate the right point to start from the recording data?
So this gets pretty complex (for both the user and the dev) and I want to avoid this.
Leaving the special mode after recording allows you to have a workflow like this:
- Disable grid.
- Record one free, not grid synced clip.
- Luppp automatically changes the tempo of the session.
- You can instantly continue recording other clips which are in sync to the first recorded clip.
This has one problem: If you record a new clip this way, the wrong BPM-Choice will make your already recorded clips be played back on the wrong speed.
It's not really an issue, but rather a feature to me ;o)
Leaving the special mode after recording allows you to have a workflow like this:
Disable grid. Record one free, not grid synced clip. Luppp automatically changes the tempo of the session. You can instantly continue recording other clips which are in sync to the first recorded clip.
I think it's both easy and flexible this way ! Sorry I didn't have time to dig on this this summer, I may have more time this fall :/
It's not really an issue, but rather a feature to me ;o)
Its not an feature to play back a clip on twice or half speed as intended. This is just wrong.
I am currently reworking the clipsync and working on improving the general way how the playback works in several minor step. After everything is working, I plan to implement a finer granularity for BPMs (so we can set something like 139.24 BPM). After we did this, it should be quite easy to align the grid to a in free mode recorded clip.
This is still quite a long way to go for me alone, so don't expect this to be done soon, but at least there is some progress :)
@kasbah @magnetophon @Nomys @harryhaaren FYI, I have a first POC: https://peertube.servebeer.com/videos/watch/e92af357-2578-4c3c-9e9b-32ab146aedc3