So how will you name your lines then? The linenumbers.
What will happend to linenumbers and notes when you zoom in and out. Could you please make some examples?
Basically, Johans solution has one difference, the LPB is constant = 1. If a newbie want’s it simple, he doesn’t have to care about changing the LPB, he can just keep it at the default LPB=4.
A couple of scenarios that shows advantages of the LPB:
Different songs or even parts of a song may have different basic timing, ie one part is based on sixteenth notes and one on sixteen triplets. Then the workflow will be easier if you use LPB=4 on the first and LPB=6 on the second, since you don’t have to remember which zoomlevel you have used on each part.
The separation between the zoomlevel (which is a strictly GUI related parameter) and the LPB (which defines a natural timebase of the song/pattern) is IMO important.
Martin:
You have a point with songs using different LPB in different parts of the song. I admit it would have been pain to have a separate zoom level for each pattern just to differentiate the timing.
You guys have persuaded me. Go with your solution! 
// Johan - keeping the discussion alive
@martinal: When do you think, this resolution feature will be implemented? The lack of it prevents me from using (and register) renoise seriously.
I think you should register now, then you will get this feature sooner or later to a good price!
And the only thing you could do that would speed up the development of this feature more, is that you register now and then vote for it as a w.i.p. user…
Is there any risk that a very much increased resolution will make renoise very cpu heavy?
Hrm…
Mini-patterns, good idea… abolishing “speed” parameter very good idea.
I had an idea a while back about how to implement triplets, etc, and it was similar to parsec’s mini pattern idea… except each mini pattern would not just represent a single line, but a user selectable number of lines.
So you could say “Within these 4 lines, I want 5 notes regularly spaced, or 256 notes or whatever.”
Increasing the “tick” to 256 per line is a good idea… but I think this should be transparent to the user… in fact internally you should use as many ticks per line as possible and for bpm… well this is why I actually hate the speed parameter, I’ve never understood it because if you change it, you adjust the true bpm from what you select in the bpm box.
Instead, you should specify the bpm and time signature, this could be different for each pattern, or even changed with an effefct half way through a pattern, the GUI display (Highlight every x lines) should be removed and this should come automatically, directly from the time sig. (changing half way down if required, different tracks could not have different bpm/time sig, so this should be in a separate column, like the send, etc.)
Combime this with the flexible mini-pattern idea and you’re sorted… as for visualisation, well I would prefer a popup box to display mini-patterns or sub-patterns or whatever they’re gonna be called, when you get there, but zooming too could be good, make it customisable from the GUI configs.
This way, you can stick to the normal rows most of the time and then insert a sub-pattern whenever you need one, that spans as many lines as you want, this is why it’s important to have max internal resolution, because someone might say I want 257 lines between these 3 rows and if this clamped to the nearest row/256 tick then you’d get some slightly off, or bizarre results.
J
Let’s look at what a resolution of 256 ticks per line means.
Assume a tempo of 120 bpm, that is 120 beats per minute,
or 2 beats per second. With a LPB parameter of 4
(corresponding to the current standard speed 6),
each line is one 16th note, or a quarter of a beat.
So then we have 42=8 lines per second.
Now each of those lines are subdivided in 256 periods,
which gives 8256 = 2048 ticks per second.
So one tick will then be about 0.5 milliseconds.
Now, if you use a LPB of 8, corresponding to speed 3,
then you have 0.25 ms per tick.
If you can distinguish time differences at that
level of detail, then I’m impressed.
To compare, Cubase has ppq of about 1500 afaik,
renoise will have 1024 with LPB=4 and 2048 with LPB=8.
Yes, I realise this is quite a high resolution timer for music, but my point is that it shouldn’t be visible to the user (or rather not directly).
You see I’m really anal and if I had to manually decide wether to use tick 83 or 84 to get a 3rd of the line I’d just go spare as it doesn’t divide! I’d much rather say “Right, here I’ve got 16 lines and I want 24 notes to be triggered (or some notes at multiples of 16lines/24 intervals) between them (ie starting from note 0x00 exactly on the line and note 0x17 (23) ends on the start of the next line)”.
I’d much rather allow renoise to pick the nearest possible tick that it could, that way if the timer resolution is ever increased or decreased in the future, or for example if the option to reduce the timer resolution on lower end machines was available, this would not affect my note placements.
This also has the added advantage of allowing me to see 24 notes as 24 lines in a little popup box, or 24 lines zoomed to fit in the space of 16 lines, (or however I chose to view such things in the GUI configs) rather than looking at 16*256=4096 lines, most of which are empty.
So you see I’m not suggesting an even higher resolution, just that the resolution is not important to the user. Us coders sure, we can handle it, but lets face it, it’s slower doing a bit of math every time you want to place a note rather than just saying how many notes you want between specified lines. Also this will not confuse new users (either tracker users or general music bods, looking at alternative software).
JayA
by the way, did you considered the idea of raising the maximum number of patterns to more than 256?
I think that adding more resolution and basing everything on LPB/BPM will lead users to “consume” more patterns, so 255 patterns could not be enough for the longest compositions (I’m using about 48-64 patterns each song).
Probably this is an exhageration, but COULD happen.
I don’t see any reason why we should have a limit on the number of patterns with the new structure we’re making. Is 64K patterns enough? Or do you need a 32bit number of patterns? 
I’m not saying you need a reason to limit them: I’m saying that the present limit of FF could be not enough… either I’m stupid and there is a way to play more than FF patterns in ReNoise 1.261
I have to admit, Martinal you’re starting to scare me 
As much as i welcome change, i think it’s also very important to remember that one of the many reasons people move to Renoise is because it’s taken the time tested FT2 model and applied it to modern technology in a highly successful manner. Frankly, from a musician’s point of view, i find the speed/bpm way of increasing resolution more than adequate. It’s clear, basically easy to adjust and understand, and although it’s ultimately not the most precise solution in the world, honestly, how bloody precise do you want to be? To me, precision is more of a technicality than a question of artistry.
What you’re saying is, that for no real reason other than “damnit i’m tired of this, let’s try something else”, you’re willing to take years and years of time tested and approved technique and jam it up the ol’ tailpipe of the people who are used to it. It’s like saying “Pianos should have a third set of GRAY keys to increase tone resolution, obviously a great idea”. It’s a nice idea, on paper, but honestly it seems like you are more interested in the technical side to making changes than you are in having people make music utilizing them.
The question ultimately metamorphosizes down to this other, rather strange question: Needless complication, do we need it?
Frankly, i don’t think so. What i thought was going to be the Piano roll “gimmick” for renoise was in some ways what it was for Fruityloops; giving users greater control and greater resolution within a superficially rigid structure. I never had the resolution problem : bump up the speed and pattern length and i’m rollin’. However i could see how some people, specifically working with essentially repetive music such as minimalist techno, would benefit from shorter patterns at a low speed but with an underlying pianoroll of “endless” resolution for the occational clicks and pops they’d like to put in in.
I thought pianoroll would add this exact element, greater control of resolution, to the Renoise package. Instead it seems like it’s “just another way of doing things”, which again brings me to believe that you are more intrigued with the technical implications of the changes than with the actual tracking part.
As a musician, of quite a few years of experience with multiple trackers in a professional environment, i can honestly say i don’t think this change would bring a single positive thing to the table. Sorry about being a troll, but the idea really just fills me with discomfort. After all i moved to Renoise because it retained the simplicity of use i missed from other packages. In any case, i’d expect this to be an optional feature rather than a complete overhaul of the concept. If you’d like to keep me, and several others i know, as customers for future versions, i’d recommend you take some time out to seriously think abuot how you’ll go about this.
@ Sunjammer:
Nothing will change! I dont get it. Why do you think this will corrupt your way of doing things?
A pattern will be a pattern as always. You can do it your way, as you always has. You have an option to zoom in when ever you need to.
The same for pianoroll. Dont use it if you dont like it.
If you need less resolution in recording situations then use a quantizer.
I can only speak for myself. I usually use double bpm and speed 6. And that is not even close to what resolution i need. Not only when recording from midi keyboard but also normal editing/typing notes effects automation etc.
I cant see nothing then advantages whith increased resolution. And I doubt it will take ‘years and years’ to implant that.
For me the current resolution is slowing me down and even making some things impossible to do.
cheers
Speed 6 is ridiculously low res in any case I’m averaging on Speed 2 200bpm these days.
Perhaps i’m rash, but i honestly don’t see the point. Sorry.
- Sunjammer
hehe… then I have more ticks per beat then you have 
So I can place notes more accurate then you can. But you have more lines per beat to work on and thus can type commands in a better resolution.
Then again I can see more things going on at once (in time. Slower scroll).
With better resolution and zooming you will have all this.
Maybe you dont need it. I do 
That’s an interesting point… Never really thought about that. I’m absolutely dependant on said “effect column resolution” though
I dunno, i’ve sort of gotten over whatever initial ‘shock’ i was in hehe. I guess it’s a good idea for most people. I should stop being so selfish.
sunjammer: the reason I started this thread was to get input, positive
and negative, on these ideas. All ideas here are not originally mine,
many have been collected from this forum, mails and chats.
The lack of good arguments against these ideas has led me to believe
they are good ideas. But I’d very much like to hear more specific
and constructive criticism on the ideas presented here if you
have more to say.
Some of my arguments:
The traditional low timingresolution of trackers are a big reason
for many people to choose other programs.
The speed concept has proven very confusing for many new (and old!) users.
When introducing new advanced features (like midi import/export) this
parameter is not very well defined, which will make it hard to find good
solutions, and which in turn will lead to more need for support
(and thus less developing 
).
The fact that many people crank the BPM to around 200 to
gain resolution is a workaround which shows
that something is missing/wrong in the software.
BPM = Beats Per Minute
Many users use Renoise together with other software,
and/or prefer to use the actual BPM of the song and not
thinking a lot of math to find the tempo.
The most challenging aspect of these (and many other new)
features are to keep it just as (or even more) simple and effective
as the old ways.
I assure you I do not wish to do this because of the technical challenges,
we have a lot of both useful and challenging ideas on the ideas list.
What I want to do, is to make things less technical for the end users,
while adding possibilities and removing limitations. I’m awaiting your response
hmm… don’t know about that. will be a little messy won’t it?
I see that it might be useful, but… I’m sceptical.
Good point. This must be thought about more. Not only this, but how all tracker commands will be applied.
Could commands like retrigs and arpeggios apply to single notes?
That would lead to yet another column per notecolumn…
Perhaps a bit crowded [Note, Instrument, Volume, Panning, Delay, Command]
Of course, then the Volume and Panning columns could have more sliding options ++ instead of delays and notecuts,
and the Command column could also have several more possibilities. And we could have options to hide
(and still use, not like hiding vol/pan today) columns in the patternview to focus better.
Also, I think an optional default instrument for a track is a good idea, often only one instrument
is used in a track and this would then save a lot of screen space.
Yes please, more of this is good.
How about replacing the GUI widget for “Speed,” which you said is no longer needed, with a widget called “Zoom.” It could be from 0-255 and that would change how the pattern is displayed. Then you could bind CTRL-RIGHT to increase it and CTRL-LEFT to decrease it and have a pretty snazzy way of editing your data without much change. It should probably move quadratically (1-2-4-8-16-32-64-128-256 as the options), which would mean it would be pretty fast to use as well.