Speed / Lpb Confuseness

General Discussion
1

I would like to continue discussing the problems and possible solutions for that problem, descibed in this topic : Song Speed interpretation changes in 1.3 and its problems

Martin pointed out that I might have confused most of you, by saying that we will do something to fix this problem for 1.3 but without saying what we exactly will do for 1.3. We both discussed this topic again. Here is a summary :

The problem :

  • Varying the speed parameter dynamically with patterneffects, may result in strange tempo interpretations in beatsynced VSTs. As speeds 3, 5, 7, 9, 11 … will result in tempo changes and not patternresolution changes for the VSTi`s
  • The concept of the speed is confusing as it has no realy musical reason, and even people who used trackers for years mostly only know that it somehow changes the tempo of the song.

The possible solutions
a ) removing the speed parameter and introducing a Lines Per beat parameter instead wich will only affect the patternresolution and never the songs tempo
b ) Taking back the change we made for 1.3 so VST`s always get only the BPM as tempo information. Meaning that if you track with Speed 3 and BPM 130, the VST will “think” that you are running at double the speed.

I explained in the original topic that I would like to remove the speed parameter, as described in a). But this leads to big compatibility problems with old songs and with the interpretation of the tick commands :
all relative pattern effects like pitch or volume slide depend on the speed parameter, so as soon as we remove it we will have a big problem converting old songs.
Further Martinal and me decided that this cannot be completly done for 1.3, as this should come together with the zoomable pattereditor, and the increased note resolution wich is not planed for 1.3 . See A question of speed for the full description of the concept.
So if we simply remove the speed parameter without adding new possibilities to work without ticks - via for example note delays - we will end up in something that is half finished and unusable. So this can defenitly not be the solution for 1.3.

Solution b ) might solve the problems that Keith 303 described but will again make it impossible to for example use Reaktor with a speed other than 6.

The solution for 1.3 :
We will not remove the speed parameter for 1.3 because of the problems described above. We will instead set this as a priority feature for 1.4 and will do this together with “making the player tickfree” and “improving the note / effect time resolution”.
We will instead make an song option in 1.3, to get back the old (pre 1.3) behaviour, to make it again possible to use for example speed for groove shuffling.
Further we will add new pattern effects to control shuffling, and improve the internal groove settings in the songproperties to avoid that people have to use ugly speed effects in the pattern to get a groovy rythm.

I hope I havn`t confused you even more now :)

2

ok totally confused :blink: :lol:

3

I realy hope this will be the final goal, cause the BMP/Speed dependence isn’t realy a thing to endeavour to keep. It evokes more problems than it reduces.

This is not the only problem, it also means that you in no possible way can’t change the line-resolution when working with VSTi’s synced to the BMP, and that is not realy an option. Then maybe some of Keith 303’s songs will start to work again but on other hand some of my latest songs will stop to work…

Ok, do I understand it right when I say that this will mean that both Keith 303’s songs and mine will work? If so: great :)

4

yes, the option is the most reasonably solution.

and indeed I’ve proposed it :veryproud: :rolleyes:

5

okay, my two cents :

I dont care how you do it and I really really dont care about that LPB value.
the only reason I used it now was to set my 120 bpm songs to 320bpm/speed 16 because I could then use those delaycommands in the panningcolumn from 0 to F, and I need that now.

I know if this F08 F04 trick to make shuffles, but I never used it, and I also never understood these groovesettings.

so all I want is the same or even a better resolution for those notedelays. (I dont use Envelopes that often, too)

but I see the problems that this LPB thing from the past brings, however, I propose that you now start caring about this XM-Compatibility, because … I mean, renoise was never meant to be a topnotch XM player and those people who havent switched yet from FT2 to Renoise … Dont know if they really count anymore.

6

Looza, out of curiosity… how come you use delay commands instead of a higher speed? I mean, I would normally use 120 bpm speed 03 in this case.

7

Agree this seems to be the most convenient option for the user.

Just a thought tho, Would it not be possible to create a master delay command i.e. like a delay column in the master track so that you could add your delay to the whole pattern. You could add your commands every second line (or whatever your shuffle requires) which would apply to every track in that line. This way you could convert your shuffle beats from older rns`s relatively easily (a bit of copying + pasting of new commands) and even vary shuffles within a pattern without affecting tempo. Would this then not mean that the speed option could be done without all together? and if the command also aplied to not just the notes but other commands could the problems with pitch and volume slides be solved this way also?

EDIT: just thought of a problem with this with conversion. The speed parameter would actually need to be kept so that previous rns`s using speed more than 6 would have the same resolution for each line + thus shuffles. It may just mean that the f1xx command could be got rid of. hmm… :huh: S*#te

8

I guess some people do not see what a delay “dx” musically means; A delay is a note drawn on position 1/8…1/32…1/64.
So why there is this Delay-Parameter dx?
Because of the bad resolution! It is another workaround (like the Speed parameter itself!) to simulate higher resolution!

You do not need neither the speed command Fxx nor the delay command dx to make shuffled beats, delays, whatever! You can make it with higher resolution even more precisly.

An example.
Imagine you have speed F6, 130 bpm and want to realize
1.) a shuffled hihat (using the delay command dx in old version), and
2.) a controller effekt (e.g. cutoff of an vst/midi-instrument)

old version:

Base Hihats Controller

  
0 D4 E4 00  
1 02  
2 E4 04  
3 06  
4 D4 E4 08  
5 0A  
6 E4 0C  
7 E4 d3 0D  
8 D4 E4 0F
  1. Delay-Problem
    What, if you like on position 7 another hihat sound, without delay? What, if you like another delay on 7 with d4?
    a ) You have to open another track, this will make your song more complex and unreadable.
    b ) you have to change the speed paramter to F03, have to change all other tracks and have the same problems like a) if you want to build more exact delays.

Both possibilites are bad because it makes your song unreadable und complex.

  1. Controller Problem
    This controller change from 00 to 0F in these steps (2) sounds crappy and not clearly programmed, you hear jumps in the cutoff. Imagine a bigger range from 00 to 3F (in single steps 01, 02, … FF) in that period with no hearable gaps; it is impossible!

Furthermore if you increase the speedparamter, you can not synchronize correctly to external instruments, (vst/midi).

new version

With a higher resolution you solve both problems!:

This is exactly the same like in the old version, only with higher resolution (no speedchange!)

  
0 D4 E4 0  
1 1  
2 2  
3 3  
4 E4 4  
5 5  
6 6  
7 7  
8 D4 E4 8  
9 9  
10 10  
11 11  
12 E4 (original position) 12  
13 13  
14 14  
15 E4 ("delay d3") 15  
16 D4 E4 16

  1. Delay
    As you see, here no position has a note which do not belong to it. (Position 7 in the first example would be position 14 in the second. And 14 is not occupied, so you could use it without opening another track) And whats much far better: You do not need to change/increase the songtempo, you have no need to set a F0…6 Parameter and need not to change the bpm. So you can synchronize it to every external renoise instrument (vst and midi) without any problems.
    What, if you like a note between pos 15 and 16? Just increase the resolution to 0…32. How easy! Could you have that powerful control in the old version?

  2. Controller
    Another big Plus of the higher resolution: You can control VST-Effekt columns or Midi-Control-Parameter much more precisly and gain great effects, without varying the speed.
    See in that example, you have no steps of 2 like in the first issue; it is a “flowing” curve with no gaps which pleases your ears.
    What, if you like to make a change from 00 to 3F in that period with step 1? Just increase the resolution! Imagine, what beautiful effects you could create!

I hope, I have shown the benefits clearly, that you can control with a higher resolution much more precisly your composing, doing all the things you have already done: shuffling, delays, speed-variations, it is all an uncomplete, complex and uncompatible alias for higher resolution.

Users, we all ( should )evolve, and this would be a awesome evolution to renoise and your composition-technique. I can not see why down-ward compability should be that important. Look at yourself. How did you start? I started with protracker on amiga, and if I would like to hear the tunes, I will reload them into the old PT. But how often I do this? Let me think, maybe 2 times a year. And then I think of the ugly limitations that program had and I would never have the idea to begin a new song on protracker, though I loved it and have protracked loads of years. And demanding compability to the nowadays tracker is really devious. I have drawn an final stroke under the protracker area, because I realized, there are better possibilies. Thats what we have to do now.

So finally I think, the speed/resolution-feature is an absolutly priority 1 feature, which should be implemented as soon as possible, because of the benefits it comes along with I have shown.

9

Looking forward to the tickless solution :) Good to have backward compatbility though. LPB+teckfree is nice, easier to handle. And i guess the BPM will be 100% exact then?

Let’s just get ridd of them ticks and improve the groove-feature instead. Actually i think it currently lacks greater time ranges only. It works, but it’s too shy yet <_<

Loolarge

10

johan : this is mainly for making drumrolls or shuffling hihats and similar. it just gets a much less static feel this way, because its not always D1 or D2 but can be D1 to D4.

11

Eh? The dx commands are there to allow you to access the full resolution of renoise while using lower pattern resolutions.

You do not need neither the speed command Fxx nor the delay command dx to make shuffled >beats, delays, whatever! You >can make it with higher resolution even more precisly.

f1xx changes in songs have come about by its use to create a quick shuffle on beats. It is convenient where scaling everything else up to larger pattern resolution or adding delay commands to every column can not be.

  1. Delay-Problem
    What, if you like on position 7 another hihat sound, without delay? What, if you like another delay on 7 with d4?
    a ) You have to open another track, this will make your song more complex and unreadable

You only need to open another column with another delay column (they apply to individual columns not tracks).

Higher resolution will tidy things up when implemented but the delay commands + previously f1xx, allow more control over how you work while ticks still exist.

12

Cie: you have misunderstood how the new solution will be. You should read “A question of speed”, linked by taktik above, for the discussion.

Among other things, the patternresolution can still be low (like 4 lines per beat, equal to speed 6), delay commands can still be used (but in a different way, and higher resolution), and groove commands that affect the whole pattern will be there (but not in the form of speed changes). And in addition, it will be possible to put more than one note in one row in the same column (read the thread for explanation).

13

Please don’t forget to spread some alpha releases to the long time users (f.e. me :)) to see if these new method will let people do the same things than the present method, plus more new things.

Remember that ReNoise’s strength is the low-level cooperation between users and developers in designing, testing, suggesting, fixing and improving phases of the developing process.

I’m 100% agree about any modification which will enhance ReNoise’s capabilities, but I’m afraid like mad when those enhancements are about to be defined.

Ninja tracker’s conservation instinct :ph34r:

:blink: :lol:

14

It seems all the suggestions made me a little bit insecure. :(
If 1.3 includes higher resolution and (optional) speed-parameter + whatever, there is no problem for me. I was just afraid, that you do not focus on the resolution-feature in 1.3 anymore.

15

Then be afraid…
Read taktiks first post in this thread carefully one more time,
because that’s exactly what we’re saying. 1.3 will not have
a better resolution, but it will be a priority after 1.3.
This is very fundamental changes we’re talking about,
and it’s not done in a week…

16

Having read through the “Question of speed” thread

Perhaps you should try again? Most things you write here has
been mentioned and discussed in that thread, and it doen’t seem
to me that you have grasped what we’re really planning.

I can’t help thinking that the way you want to implement
higher resolution is a bit like reinventing the wheel.

How? I think it’s more like we’re trying to fit the wheel into a tracker :) .

Why not employ the BPM / TPQN (tempo / resolution)
concept, that’s been successfully used throughout the MIDI world for
ages.

I can’t think of anything you can do now you couldn’t do with a
simple BPM change, as long as it can happen anywhere in the song (F0xx).

Which is why we will remove speed (see about grooves below).

The only difference from a traditional PPQ (Pulses Per Quarter note)
and our planned LPB (Lines Per Beat) / 256 ticks per line is that
we will have a basic time unit (a 1/LPB quarter note) as the usual line length.
The user can zoom in from that to get more detail as needed.

(PPQ = LPB*256)

If you really read through the thread, this was already discussed.
It’s better if you comment on the discussion there, I really don’t want
to do this all over again.

About BPM changes, yes you can do a groove with BPM changes.
But it will be more convenient to have an additional groove command,
which sets the actual BPM to a multiple of the current. This will keep
the groove (or swing if you want) separated from the BPM, and is much
cleaner and easier to work with, specially if you want to change the
basic BPM at some point.

An example:
By varying the BPM multiplier with 2/3 and 1/3 on each eight note,
you get a common triplet-like swing. Now you can simply copy this
sequence of commands continuously everywhere you want this groove.
If you later want to change the basic BPM somewhere, but keep the
same groove, you add one BPM change command somewhere,
and the groove feeling stays the same.

Note delays? Retriggers? Note cuts? No problem at all - place the
note(s)/note offs exactly on the timeline where they should occur with
the desired TPQN resolution and that’s it.

This would remove one of the tracker advantages, quick commands to do
special note actions. In fact, we should rather add more of these!
But otherwise, yes, that will always be a solution and is one of the
reasons for the new structure.

Instead of LPB values I would suggest having zoom level definition
of more musical origin - 1/8th, 1/16th up to 1/TPQN-th including triplets
and user defined zoom levels.

And how is this different? Only in the name.
With a LPB of X each line will be 1/x of a beat, or a 1/4X note.

Perhaps using the MIDI line number format (measure:beat:line) would
be more communicative than pure line numbers here.

Perhaps a good idea, yes. I assume with “line” you mean
a PPQ pulse/tick and not a tracker “line”?
But then we would need some way to represent measures.
(and to be complete, measures with varying signatures…)
Or we could do a middle thing, beat:tick.
Or beat:line:tick, which fits better with the LPB giving a basic time unit,
IMO this might often be easier to visualize.

What do you think of such a solution?

Not much new here. Looks like you’ll like the planned changes.

I’m sorry if this is a bit chaotic, but I’m writing this in a hurry. Hopefully,
my basic idea is clear anyway. I’ll be happy to describe it in more detail
and broader scope, if you want (during the weekend…).

You’re welcome, but it might be better if you do this in the original thread.