Thanks, I finally got it now!
… must’ve been the italics that made the difference
That’s what I meant with my zoom talk.
But won’t this in some cases display incorrect delay-values, if you for an example go from 3 to 4 LPB? Maybe not a greater issue, I suppose, if you can just zoom in to get the true resolution…
Ok… now I feel really stupid. With resolution, I assume you mean LPB?
And this will be a GUI gimmick only, instead of something concrete like a tracker-command like the old fxx-command. So what would a fraction of a beat be?
Blah, someone draw me a diagram (with friendly colours)…
A lot of people here are talking about significant changes, but all I really want is speed with decimal values!
An example - when I jam with a DJ friend of mine, and use Renoise - my friend might have two turntables beatsynced (matched in speed). When I join, my tempo might not be exactly the same, and I would end up adjusting the tempo all the time, instead of creating music!
It would be great if Renoise had the option for decimal BPM values, instead of just integer values. My own music is almost entirely in the 125-135 bpm range, so each BPM represent a rather large step…
It would also lift the software quite a bit towards the “professional” level where we all want it to be
i noticed something last night that’s sort of like your proposed resolution hike and it’s wicked.
if you use the advanced edit menu to “expand” the whole song, it automatically adjusts the length of all the encapsulating patterns. so you can, in effect “zoom in” by applying “expand” to the whole song and then doubling the speed.
i don’t know if someone’s already given you guys props for that one, but it’s positively rad.
You can do this, ie “zooming by expanding the whole song”,
easily in Renoise already. As for the concepts discussed in
this thread, they’re not started on yet (you might have noticed
we’re in the middle of finishing the 1.5 release).
oh, i must not have known this because modplug tracker was such a shitty attempt at an IT clone that i’ve spent a total of about three hours using it, most of them extremely frustrating and unpleasant.
When removing the Speed parameter, put Timing Res2tholution instead, where you could show things in f.ex. (-?)1/128th, 1/64th … 1/4th(+?)view. Could be switched to “0ld5k00l” view in configs, where speed 3 would be like like having 1/32th view.
Triplets: Either hotkeyable triplet view in current zoom level (making every 4 rows 3), or possibility to either paint an 4-row area and press make triplet key (or right clic-choose: make triplet) or key function to make last 3 rows triplet starting from the first row. The triplets then could be viewed like 3 rows in space of 4 rows, and could be removed by deleting all 3 notes, or painting the triplet(s) area and press “make triplet” again, which would remove the triplet setting (or right click and choose “remove triplet” from the place where “make triplet” was before the triplet was made).
Or if the triplet view is chosen, triplets could be displayed in slightly faded coulour to state that they cannot be edited until you press the triplet key, and when that happens, the colour balance between straights and triplets invert to indicate the current mode.
I read the lines per beat and triplets thing, and I think it’s pretty much same as switching between triplet and straight mode. The real resolution could be static, just make it high, like 2048/beat or so.
Pattern commands could be implemented by making commands independent “note-events”. When you add a command Renoise actually adds command-note (not displayed in note column) that lasts as long as current zoom level allows it to before it stops at the next row. Then you have a functionality of the tracker integrated to new speed concept. When zooming in it could show as continuing command:
Retrigger would be used to retrig not in ticks but in th’s and th-triplets (1/128th note, 1/128th triplet… …1/4th, 1/4th triplets). Would add another fast way to make triplets, and the idea is transferrable to arpeggio speed set. What’s more, one hex is enough to set the whole range of speeds.
Pattern length rises as an issue here. Maybe easy-to-adjust default pattern length option for new patterns (in 8 or 16ths), and possibility to alter lengt individually in 1/16th note resolution, or length adjustable in rows within current zoom level?
And I don’t like the delay column (slow to use & bit confusing), but in the other hand, who forces me to use it? It could be used to humanize the timing of the notes, which would be a great feature to have, and some subglobal grooves. Global grooves could be set from Groove Control Panel, globally and per track maybe (at least on/off), and adjusted with pattern commands if necessary.
e:Now that I think more of it I could be really happier with just 2 different Zoom modes (was it already discussed?), 1/32th and 1/64th, with ability to humanize timings and make triplets as described above. Maybe 1/16th too for working with low speeds in long patterns/navigating in and handling enormous ones.
But for flexibility, does it hurt to have a little more?
Really like the idea to increase the resolution, but why not keep it simple:
Keep the speed button/ command for all those “old skool trackies” out there who would like to create a strange groove with Patternlengt/ BPM/ Speed. If you’re confused about it, just don’t use it, because there is an alternative. ->
Introduce a button (per pattern) for increasing resolution per beat by adding lines (4, 8, 16, 32, 64, 128, 256) with zoom +/- level. If you zoom out you can’t see the notes ‘between the lines’, you can solve this by giving a dirrent colour to the steps involved.
Drop the delay command. If you work with a resolution of 256 per beat, you don’t need the delay command, because you can’t hear it. This resolution is enough to create every groove you’ll ever want, all the professional sequencers on the market have proven this.
With this, the idea of more events per line can also be dropped. The increase in resolution will also give backward compabillity with the delay command. MIDI has a resolution of 256 (127 most of the times), wich gives compabillity with MIDI in/export.
Introduce a BPM tempo command (alternative for speed)
Having more than one timing solution is everything but simple.
Besides, some of this doesn’t make sense. To have a resolution
of 256 ticks per beat, either we have to use 256 lines per beat
constantly, or more than one note per line and/or some sort of
delay command has to exist. There is no way around that.
MIDI has a resolution of 256 (127 most of the times)
This is wrong. 256 and 127 has little or nothing to do with timing limits in MIDI.
Could Renoise optionally simulate a speed of 6 while internally working with a speed of 3, for example?
So we’d have the usual ‘Speed setting’ and next to it a ‘Shown Speed’.
I know, it’s again one parameter more to set for the user. But I’m not sure if it is that confusing.
Say I start composing a song with a speed of 6. The shown speed is also 6.
If I change ‘speed’, then ‘shown speed’ will always change to the same value as ‘speed’.
I may not set the shown speed below the real speed (it makes no sense to show a higher resolution if my real resolution is lower).
But I may set the shown speed above the real speed. So in a situation where ‘real speed’ and ‘shown speed’ are both on 6, I can change ‘shown speed’ to 12 . Certainly the shown pattern would be half as long then.
Notes which would appear between two lines could still be shown with a delay command. It works already very good with the imported MIDI files.
Thanks, could you use another word next time, please?
This is a thread for brainstorming. Did you see me critisizing any idea like this? I tried to think about the problem and that was a possible solution. It’s either helpful or not. If you don’t agree, say ‘I don’t agree.’ None will tell you ‘You should have better said that it’s dumb.’ .
No problem. Maybe I was a bit too sensible about this, so excuse me.
Back to the topic, I had read your idea and I liked it. But I thought about a problem with songs where the speed parameter changes (beat shuffles, simple speed changes in certain patterns). Correct me, if I’m wrong.
Say you are playing a song that one’s speed is 6, then 3, 6…and so on.
Now, if I’d be playing it with a resolution of 1/32, I’d get the full resolution on every speed. If I’d play it with a resolution of 1/64, I’d have a full view whenever the speed is 6 but when the speed is 3, I could miss some notes for example. And we want to have a static view to avoid confusion, right? (so no automatic changing between 1/32 and 1/64)
I’m just afraid that one would be confused if the played song suddenly does things which you don’t see, just because it internally changed its speed from 6 to 3.
That’s why I would at least show those notes with the known delay effect whenever the resolution would be ‘too low’. As said, if you import a midi-file, you can say with wich speed setting it shall be imported (config). And if it’s necessary, then renoise realises the (more or less) exact note position with a delay effect. In our case it would be just showing delays.
Oh, I see. You pointed out pretty relevant fact.
But the main idea of mine was to get rid of the “speed” concept for good, so that only setting affecting actual playing speed would be BPM setting. But I see that this would pretty much destroy backwards compatibility for some songs where the speed changes, as this would change only ther resolution in which the notes are shown. That’s why we would need those better groove controls. The old Speed would be like Zoom. Sorry if I used bad words to express my ideas.
And you’re right, delay colmun is pretty much a must for maintaining full potential of resolution improvement.
edit:
hmm… maybe replacing speed change command with some BPM multiplier/divider thingy, and make renoise pre-calculate actual BPMs for songs created in earlier renoises when opening them? Also if changed with pattern command the change should always be relative to original BPM value that the song was set to. Or then just rename speed levels as below.
This may or may not be on topic here, for that I apologise. You guys have been discussing the use of the delay column a fair bit in relation to resolution. Shouldn’t the first thing to change be the resolution of the actual delay column itself? 05 ticks is a little to low for me at least.
laurence, yes. indeed the first intention is to get a higher resolution.
The idea is to have a high resolution and be able to work with a low pattern speed (because it’s not always easy and clear to work with high speeds).
This can be realised with the trick mentioned above. Instead of the speed parameter, you’ll have a pattern zoom. That means that your pattern runs with a very high speed but you ‘zoom out’ to 1/32 for example.
Now there is the problem that only every second line is displayed. The delay idea is just to show the notes from inbetween even if you’ve zoomed out. We don’t really use the delay command to get a higher resolution, otherwise there wouldn’t be anything to change.
telepatu, Renoise 1.281 already did the precalculating. So you had a speed command but it would just affect the BPM actually. This ‘precalculating’ became fortunately an optional feature because:
Some VST(i)'s which make use of the BPM-information began to click and crackle or just behaved strange whenever the speed command changed. Because the speed didn’t affect ‘speed’, it actually made Renoise send different BPM values to the VST(i).
Ah, I see, thanks. There is one question that springs to my mind though. I’m sorry if this has been asked before, I was finding it difficult to follow the previous discussion, so feel free to not answer this if it’s just repeating previous posts.
My question is this. In maximum zoomed in mode (i.e. can’t zoom in any further), just say every line on the screen has a note instance in it (this is an extreme but possible case). If we then zoom out, how would all of the note information be displayed? If we displayed every second line or so, wouldn’t we be missing every other second line?
In other words, wouldn’t the information in the delay column be relevant only if there was the correct note instance beside each entry? And if that is what is being talked about, then in the situation above where every line is already filled in maximum zoom, how could it zoom out at all?
Sorry, I didn’t find the time to read the entire topic thoroughly, but I didn’t see it mentioned…
It’d be nice, imho, to have the possibility to set the bpm to (at least) to a half bpm precision.
Because right now I work at double bpm (200bpm for a 100bpm song) also for that purpose.
Edit: I just wanted to add, that this (using the actual -not double- bpm) would be also much better for compatibility issues with other programs and VSTs.
sorry, too much to read here so probably someona has said this…
it’s about visualization. my idea is: when there hidden non-empty lines because of zoomed out view, draw intermediate notes/effects (and other things “between” lines) between the lines respectively to position, visually “covering” notes/effects before it and “covered” by notes after them. ehmm…
for example:
if we have something like this:
…we zoom out to this:
…the note d-4 is drawn between c-4 and e-4, like this:
it’s like C-4 covered by D-4, and D-4 covered by E-4.
i hope someone will understand this it would be nice if developers did thing like this
