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
Set tempo based on recorded loop #65
Comments
Its not too difficult a feature to add actually, and its something that is indeed very useful. |
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. 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. |
I am not sure. In my workflow at the moment I am not too concerned about The pop-up, asking you for the number of 8ths (or maybe beats/loop would be I am not sure what effect the time stretching has. SL does have some |
@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 672429d, 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: 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 |
Another vote for this feature. 👍 |
Another vote for this feature +++ I need badly this feature on luppp |
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" ? |
Is there any news regarding this ? It's been pending for ages... |
@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. 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. What do you think ? |
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 :)
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:
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? |
I kind of knew this would be a problem :)
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 :
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...
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... |
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 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. |
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):
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 ?
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:
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:
|
It's not really an issue, but rather a feature to me ;o)
I think it's both easy and flexible this way ! |
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 :) |
@georgkrause Sorry for the late reply! I watched you video but there was no sound! Thanks for working on this though! |
@magnetophon Thanks for the interest. This was just a first POC so I only did a first video without any sound. There is a full demo of everything which I planned to release as a fork of Luppp called Loopp: https://peertube.servebeer.com/videos/watch/e52aa296-7aa7-4200-be55-a2d690c8e3f9 But after some long discussions and because of some personal stuff this fork wont be released to the public. |
That looks great! Too bad you don't want to release it! |
BTW, is that a Fusion wristband? I'm in Lärz as we speak! |
@magnetophon Jeah its from Fusion 2018, needed to skip this years sadly but was there every time from 2014-2018 (except 2017 of course ;). I did a fork of Luppp called Loopp because I wanted to push the project forward without the limitations of a project which is part of a pack. But after a lot of discussions I think its a bad idea so split the project and its better to get the changes into Luppp. But currently I can't care for it. |
Ah, that sounds much better than what I originally thought you meant! :) Usually when people say they don't want to publish code yet, they want to clean it up first, which is understandable. Is that the case here as well? |
Hey Bart/Georg! There's various options - but unfortunately I just don't have much time for OpenAV at them moment, and what little time I do have I tend to prioritize to Ctlra lib. I'm open to options as to how we can make Luppp a "community maintained" OpenAV project or something, that gives other developers more/easier control/direction of it - I just don't have the time (and dont' see that changing very soon..). Thanks for the input though, and if there are suggestions then lets have them! (Perhaps we can open a new ticket if we're expecting a big discussion - just to no derail "set tempo" thread too much! :D ) Cheers, -H |
@magnetophon I already sent the changes for review and we are already in a process of discussing the future of Luppp. I would like to stop discussion here now, to keep the issue clean. For further question, or Fusion small talk, dont hesitate to send an E-Mail or open another issue, please. |
Cool, thanks! |
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.
The text was updated successfully, but these errors were encountered: