Tempo stuff (time-shifting et al)

[ornithologistnightmare]

me again, trying and failing to make extremely loud music because that's how the natural order of the universe is structured. here's two suggestions from an idiot who has no idea what she's doin':

the (theoretically) easy one: non-integer bpms (two or three decimal places).

the slightly harder one: time-stretching for AFP.

i'm aiming to recreate the sounds of experimental hardcore, especially those from hcn, hangars liquides and bloody fist records. the latter's artists produced a lot of lo-fi jungle and breakbeat hardcore in addition to the usual angry hardcore and speedcore.

rn i'm busy trying to get some break loops into my tracks whilst using vsts over wine to make some dirty kicks. however, being the pedantic mess i am, i tend to get obsessive about timings and using AFP by itself doesn't do the trick. however, searching for a free vst that can perform time-stretching (maybe with optional vibrato for the oldschool nuts like me) seems to be a fool's journey!

inb4 learn c++/qt5/synthedit/whatever and code it yourself: doing so is particularly depressing and long for me and for some reason it feels like it's exclusive to me. getting results seldom seems to work, whether it's my environment, the libraries or my code itself. by the time i'm done, i'm bored and i'll have moved on.

[Spekular]

Non-integer BPMs seem really unnecessary, since you'd barely notice an 0.5 difference unless you're at a crazy low BPM. You could fake 3.5 BPM (for example) at 7 BPM if you really wanted.

Maybe I'm missing the point, though.

You could always time stretch in Audacity as a workaround for either issue.

That said AFP timestretch would be nice.

[ornithologistnightmare]

unnecessary bpm values

not for .5 and .25 values, at least. some people might wanna keep the time signatures right. also, it shouldn't be hard to do anyway and it won't affect the ux by even a small extent. it'll just be useful for pedants like me to have.

use audacity

sure, i could do that, but it would take ages due to the lacklustre workflow. i also can't do it in realtime. also, what if i wanna change the bpm when i'm halfway through?

[Spekular]

Well obviously it's not ideal.

You should look into "chains" (iirc), they let you apply a preset operation to a bunch if audio files. You might be able to set up a chain that exports an audio file at a bunch of different speeds.

Alternatively you could use some external tool and set up a macro, or maybe find other software that's better suited to it.

[ornithologistnightmare]

chains

i know about those and i've used 'em before. however, i've got different tempos for my samples and having to load the samples again and again for each track is annoying.

external tool

...such as?

[Spekular]

Such as this.

As far as I'm concerned AFP time stretching would require:

1. Fleshing out a description of the functionality (Stretch by %? Stretch to a specific time? What amount of precision do we allow? Do we include pitch shifting functionality?)
2. Designing an intuitive UI for the feature that integrates well with the current AFP design, and then implementing this UI.
3. Finding a library that meets our quality and performance standards, and has a license compatible with ours. Ideally it'd be actively updated, otherwise we'd need to fix any issue that come up ourselves.
4. Integrating the library into the automated build process and the build instructions.
5. Tying together the library and UI to work for a single session, then allowing for loading and saving, and potentially writing an upgrade for AFP presets from earlier versions.

I'm not saying it's not a good suggestion, but it would probably have to be post 1.2 at best, so for now you'll have to do with some sort of workaround.

EDIT:

To quote musikBear

http://superpowered.com/ I dont know if any of these could be of interest, but there are f.i. a library for pitch and stretch opp. http://superpowered.com/free-open-source-time-stretching-pitch-shifting

Just wanted to show uall

[Spekular]

I checked how BPM is handled.

• BPM is stored in(?) bpm_t
• bpm_t = uint16_t
• uint16_t should have a range of 0 - 65535
• LMMS has a range of 10 - 999 defined in Song.h

There's room for one decimal place of precision without changing the max tempo, using 0.0 - 6553.5 The tough part would be making sure this is handled properly everywhere. It should be possible, I suppose.

Alternatively we could change the type of the BPM to something with a higher range. That might be a better solution, but I feel like that could bring other problems and be a lot of work.

I could be wrong on any of my assumptions though. Could someone else please chime in on whether this would work or not (and if we want it)?

EDIT: Also, this probably ought to be two separate issues.

[ornithologistnightmare]

bpm

sure, sounds pretty good. 1dp and a range of 5.0 to 2,000.0 bpm should be neat.

description of afp time-stretching (Stretch by %? Stretch to a specific time? What amount of precision do we allow? Do we include pitch shifting functionality?)

a switch between tempo-synced rates, specific times and percentages? maybe a separate one for the precision and a toggle for the degree of pitch-shifting (though that can already be done through ladspa plugins).

try these workarounds

thanks, now all i need is a heap of cash. (why are they so expensive REEEEEEEE)

i guess i'm gonna have to do it the long way for now

[Rossmaxx]

i feel like we need decimal bpms anyway, since most daws have it. not much extra code and it might come in handy for someone who might need them. i am working on a track where i automated tempo. decimals make it easy to see the tempo change. we can go for 2 decimal tempo.

[eegorov]

Hello! I would be glad if it was possible to set decimal BPM.