I’m wondering if there is any planned update on this matter. It has probably been requested before but there doesnt seem to be any new info on this topic.
I think this is quite crucial to make pitch bends or other effects at pinpoint precision. I feel a bit handicapped sometimes when I want to pitchbend a note down and then up again within a “line”. The updated automation resolution was nice but it’s not enough… At the standard speed setting 6, there’s only 6 tick per line.
That’s far from enough so i hoping there’s some planned improvement =)
Maybe we should devide each line in milliseconds, this would remove the complete speed-option as each bpm setting will automatically have more or less mseconds.
This would however probably require the volume and panning columns to be extended by two digits so that you can use at least over 4095 mseconds (or over four seconds) per line if the bpm is set very low.
This would allow more smooth transitions in various commands and automation values, but would break the old tracker system in quite severe ways.
I think the speed setting is still a good thing to have, but it shouldn’t be linked to the tick resolution. The main reason i use 03 instead of 06 for example is to get a faster feel and a bit more accuracy placing notes. I see it as a dividing tool … deviding 1/4 to 1/8, 1/16, 1/32 etc… using the speed setting this way along with a lil more accuracy using the dx command in pan and volume column should be more than enough…
Volume and Pan column
I dont think it would be necessary to change the whole system. The volume and pan column could have a quite rough setting. d0-df (16 steps per line) no matter what “speed” you set. it would be the same as ofsetting 6.25 percent of a line with d1 and 93.75% with “df” … and 50% with d8. Offsetting by percentage using these columns wouldnt be much different from the 9XX command starting to play a sample at a certain percentage.
For even more accurate ofset you could use the effect column. Working with percentages of a line or divided in hex count is probably the easiest way to go about. (In a tracker point of view)
Effect column or Delay column?
00-FF (256) ticks is more than enough for acuracy. so either using the effect column or adding a special delay column would be the best thing i think. The delay column could be hid by default just like the pan column. Since you can hide and show the columns you probably wouldnt have to worry about getting too many colomns … you probably dont use delay column on every track.
Automation
And for automation accuracy. 256 ticks per line would probably be enough as well. And the possibility to zoom and draw curves with that accuracy would certanly come handy. skipping the white dots that snaps to the lines would probably be a good thing too. Making stronger grid lines on the “lines” should be enough for guidance. maybe small numbers at the top of the grid is good too.
(Off topic) *** personally i would prefer if the automation track was’nt horisontal as it is now. to fit better with the pattern editor it could be expanded the same way “adv. edit” is. that would give you better overview and you dont have to look at both an x and y axis moving. If a horizontal clip arranger is going to be implemented i thing the horisontal automation editor is better. =)
All in all, i dont think the ticks per line should be connected to the speed setting. It should be a global value not affected by the speed setting at any time. To not mess things up (confusing old trackers) setting the speed to 3 instead of 6 is actually a simulation doubling the bpm (but not shown) so setting 3 would actually be the same as 6 but playing at 250 bpm instead of 125 (if 125 is the shown value)
I’ve read that post and posted there before, the ideas there were a bit too wild for my taste, so this is just a suggestion of an increase in ticks, not changing the whole concept with adding a zoom etc =) i don’t believe in changing they way a tracker work. Increasing the ticks per line is enough… it should be doable without interfering with the way things work at the moment.
Keeping it as simple as possible and letting a tracker be a tracker is the main thing…
well… IMO your arguments (if there was any? ) for not implanting a zoom etc are widely exceeded by the possibilities you get from a zoom.
And not in a single word that was written it that thread I can see anything at all being changed by default. It’s just another one of those: ‘Don’t use it if you don’t need it’.
You know… your suggestion just pretty much exactly described what was discussed in that thread. So that would be very contradictory of you to say that this ‘will change the whole concept’.
You can be damn sure that priority number one is to never change the very basic of the tracking concept (from the end-user point of view). But we must dare to expand it and make it better.
It’s pretty obvious for anyone used to other sequencers how limited a tracker can be as well. I find resolution and zooming to be maybe the biggest limitation.
Igreed. if i dont want to use a zoom i wouldt use it. But i would feel like I was missing out on something. I wouldnt mind there being a zoom as long as i didnt have to depend on it to do the same thing as i can do using the zoom. There should be 2 ways that is…
And the argument of not using a zoom is marely that I personally think the effect codes should be able to do the same thing as zooming and editing a zoomed area. The thing i dont like about zoom is that i won’t see what’s edited within that line unless i zoom in and check it, probably possible to see it anyways but worried things will get too messy.
I probably shouldnt continue this discussion in this thread. But i hope you get the point.
To sum it up:
I’m just looking for a higher tick resolution per line. Using codes (as usual) to for more accurate delay effects and pitchbends.
The pattern editor itself wouldnt need that much bigger resolution for anything else than delay, if the automation window and resolution there was improved. For example: Besides from delay I use pitchbend and filters quite frequently and the only thing i’m missing is better resolution on this. I would like to be able to pitch down and up again within a line without having to zoom. (preferably by using an improved automation window)
And for pattern editing and effects sliding commands the same way 01xx & 02xx … and 06xx & 07xx work would be very useful, especially if the worked for vsti’s as well.
triggering a note within a line could be done with effect commands rather than with a zoom, =) that’s all… or rather there should be a way to do it in both ways if the people seem to prefer one or the other way equally much.
Ohhh and one more thing… if increasing the resolution of tick between lines. would it be possible to implement a sort of “read ahead” feature that reads the effect settings in the next line while simultaneasly starting to play the current line, and then automaticly makin a smooth transition of these effects across the ticks per line.
Line 00 C-401 60 – “2264”
Line 01 ------ – -- “2202”
Renoise should automaticly generating the inbetweens and trigger them descending from 2264 to 2202 .on every tick until line 1. That would make smoother effects changes between lines. not so steppy.
Enhancing resolution could even be as easy as doubling all speed values:
what now is speed 1 should be come speed 2, 2 => 4, 3 => 6, …, 32 => 64.
By implement this change you’d get doubled resolution immediately (at cost of more CPU power, I think)
F0xx command has enough range for this. The only drawback is that Dx and FX command time range would be halved.
) for not implanting a zoom etc are widely exceeded by the possibilities you get from a zoom.