Really, No Beatslicers Are Needed

well i take what you are saying

but i am still wary that it may become something more cumbersome rather than is necessary

a healthy bit of skepticism never hurt
your points are fair
i agree that when using renoise…the entire song is difficult to visualise…however i still dont see that a visualisation is necessary

i consider the non visualisation of wave forms to be an advantage of renoise…you are naturally entitled to your opinion…but really that goes without saying…

i dont mean that we should all just use 4 tracks and yes the improvements have been quite amazing since 1.4 or whatever

there will however be a time when renoise is simply complete

that is possible isnt it?

i consider it an instrument…and therefore have a hard time imagining constant improvements that do not detract from the tracking ethos

a craft takes time…yes time saving is great but like i say…i am wary

…The solution is simple…

Stick with 1.8 if you dont like the advancement. Nobody forces anyone to upgrade <_<

I don’t see problem with beatslicer… if don’t like it just don’t use it. I’d like to use both bs effect and pattern commands such as 9xx.

good point about not upgrading

as long as all versions are left up to be downloaded

yeah, just don’t upgrade. and backup a copy of 1.8. problem solved.

nah,

beatslicers are bloatware,
period.

Are you sure? I’m not a programmer but it doesn’t seem such feature would take lots of disk space or RAM. Or am I wrong?

Anyway much is discussed earlier about this topic here and also before this.

i think i may have been too harsh with that statement.
what i meant was.
having a beatslicer in renoise, in my opinion would set renoise on a path to ‘become’ bloatware.

i do have reasons too.

the beatslicer as a concept is always mouse driven.
however the beatslicer concept doesnt in fact need to be mouse driven.
however through time it will no doubt become completely mouse driven.
so much an to the point, that eventually renoise cxould become completely mouse driven an overly complex.

please dont get me wrong i am all for tighter resolution on sample offsets, but a beatslicer?
i see a beatslicer in renoise as superfluous, since of course we already have that capability through effects commands, which only needs refinement.

I also love the way Renoise is now, compact and small in size but super-efficient in music production. But in the path of improvement there will be no ridding of getting larger in size and more complex in structure and of course that’s inevitable. No one can predict how complex or large Renoise 5.3 would be for now, but we are all sure that it will include tons of improvements.

Yes, and all the discussion here is about the ONLY NEED OF REFINEMENT. Maybe this refinement would be done just by adding new effect commands (for using combined with 09xx) without the need for a beatslicer too.

noone forces you to use new versions of renoise, so if you are happy then be it, if others are missing something which can help the process then it needs to be implemented if trackers wouldn’t evole you would never have renoise , if old trackers didn’t want to have vst support you wouldn’t probably use renoise at all , so the advancment is necessary.

I’m gonna pull a CTGMusic here and say the following:

Generally, I agree with dblue.

[http://www.uploading.com/files/1EWJLI2O/Be...agung_.wav.html](http://www.uploading.com/files/1EWJLI2O/Bendish ____ Gedankenubertragung_.wav.html)

save target as…

i am by no means a pro at this tracker game but this is all just one full lenny white song cut up in renoise

and a 4 second snippet of kool g rap

no vsts or plugin effects

pure native renoise

no soundforge either

no external editors

yea you might not like it but it surely proves that beatslicing is not really necessary

anyway judge for yourself

thanks

g

i think yuo are not right about beat slicer
dont look to it in real meanning BEATslicer
900…9ff acuracy is 1/256 per whole music sample
with long samples 900 komand unusful
so slicer (not only for beat) would be very OK

get phatmatik. and surely there are free beatslicers too…

it’s the same thing as “i want have c64 emulator, renoise-lite for children, AHX player etc. built-in…” nonsense, renoise is great because the aplication itself is beeing developped, not the shit around… imho.

Renoise suffers a serious WEAKNESS in handling long samples*. In the path of making renoise a more public and reliable software whether by a beatslicer** or any other useful new feature it would be wise to surmount this weakness.

  • When I speak of long samples, I do not refer to those cut/paste-able or reversable drum loops for making more taste. I’m speaking of long recorded samples that you can’t modify easily, assume a long reverbed vocal, or tenor sax, or a complete band maybe, or something like that, recorded with lots of syncopation. I also don’t say that it’s currently impossible to handle such samples in renoise, but it certainly wastes a lot of time.

** Please contemplate about the term BEAT-SLICER. If the name is beat-slicer it doesn’t mean that it’s only for handling BEATS, which imho renoise does not need a beat-slicer for beats, beats are easily handled using the current features available in renoise. Beat Slicer is discussed in this forum because it can be a way to improve the handling of long samples in renoise. And of course there might be many other ways more efficient than this one.

Actually what i feel, is what combining the Renoises traditional tracking method of handling samples with all the benefits of beatslicing (or the 9xx command if you will - since they are actually the same because they already share all the same features) for the music makers all over the world would be just like having E=mc2 -the theory of relativity and quantum physics combined into one ultimate solution that covers it all. A sample mangling tool that has the good sides of both tracking and beatslicing… With renoise i’m actually getting this feeling that there is a possibility and i’m also now seeing the solution how to do that… It is really possible only with this software at this moment.

What is really important when trying to combine these two worlds is that the slices in use should have both the ability to overlap and the ability to not to touch eachother. One of the things that we’re able to do by using a single hit, is that you can have a little part taken out of the beginning of a sample without affecting the other drums lengths or their playback. Or you can have a little part from another samples end at the beginning of another. This is something you cannot do by using a beatslicer or any other substitute as the 9xx command.

No company has ever made it possible to have overlapping slices nor have any of them even showed signs of the possibility to have individual loop settings or envelopes for the slices - not to mention the ping-pong looping of individual clips… and that is why traditional tracking wins in most cases.

One of the things that cannot be come around by composing stuff by slicing beats is how to maintain the original groove of the loop while slicing the beats. You can do this using the beatslicery 9xx command and using a normal beatslicer such as Zero X beatslicer, but so far you cannot cut the loop at every 8th or 16th note at their exact measurements.

So you can do this in the 9xx but not by using the traditional way of slicing. But then, when using the 9xx command you cannot to control the starting point of an individual hit… again you can do this - but only if you use individually sliced samples. Also, if you have ten individual drumhits loaded you cannot change their tune or envelopes at once from one single slider, but you can already do this for multiple hits when using the 9xx command. Why not combine these features?

What in my opinion could be a really easy solution for this, would be a combination of “Parenting renoise instrument” - that would as the name suggests, act as the parenting tune & envelope cotroller for all of its child clips -, the 9xx command …and a beatslicer.

Lets take a look at how things would look…

Here is the normal sample view for the Renoise instrument with it’s parent mode - or call it beatcutter or 9xx command mode if you will - switched on.

This is where you make the main edits for the child instruments. You twiggle the start points of clips from here (you can control the start points from the individual clips aswell as usual) and in this instrument you also have the master envelope s for all clips - be it pitch, panning or just volume envelopes. This is a traditional feature of beatslicer and 9xx -effect command in that you can have a parenting envelope for the amplitude envelopes of all hits. In this case this is really only a parenting envelope because unlike other beatslicers, the slices can have their own envelopes too)

If we have a parenting instrument for all the clips the samples tunes can also be changed on the track by using the transpose keys shift+f1 and shift+f2 as usual in which i think most of us are accustomed when making beats using slices. This solves the problem leading to drumhits changing places of the standard tracker/ renoise instrument when pitching multiple samples on a drumtrack.

You can control the beginning points of samples from here on, as well as also from the individual clip editor which would look exatly the same as usual. Here we have a 1 bar long clip of the amen loop. All that the user actually has to do before renoise understands the measurement or bpm is to type in the amount of bars you have in your loop. After typing in the amount of bars for renoise, you can then have the hitpoints eiher magnetized to the measures or edit them individually. (This is equal to preparing a loop for beathandling with the 9xx effect command.)

Note that slice 3 is somewhat shorter than its corresponding measure and it also ends before the start of its seconding slice. Slice 5 is also overlapping slice 6 and vice versa. So this is actually not a beatslicer… the parenting renoise instrument is just a “master editor” for all the individual clips of the sample.

If we then doubleclick on the 3rd slice thats the edited snare of the amen with loop-points, it directly jumps to a familiar view of the instrument.

Here you can edit the samples properties such as looping and start&end points just as usual. Only the cutting and pasting of events is disabled. This is because there is no need to cut anyting. Being able to move the end and start points inside the mothering instrument into both directions removes the need to do any cutting and pasting here. (Enabling cutting and pasting stuff in the individual hit -view would also mess up the timings and assigned hitpoint positionings in the parent instrument and we would not want that.) Therefor all the cutting and pasting can be done in the “mother” clip.

Also, note that the endpoint of the slice thats viewed in the mothering instruement - or slicer - is derived from the end-point of the loop. Not sure if this feature is necessary but i think it would be kinda neat if the sample editor view understood the ending point of the loop and viewed it - as seen below on slice 3 - as the end of the clip ;):wink: The clip should be showed normally in the sample editor from its real start to end to prevent any hassle with editing.

Here is the main envelope view:

It is not that different from the usual… it is just hosting the the parent instruments controls. Note that the envelope is not applied to the loop itself but on to its slices… So, tweaking the amen by switching the master envelope on and off would sound domething like this. This is also usually the advantage of using a tratitional beatslicing method or the 9xx command. (demonstration made using renoises envelope and the 9xx command)

It also has the master tune fader at the bottom for all the child instruments.

Okay, how do we implement this feature so that it could serve everyone using renoise?

As we know, there are 3 ways that people compose beats in renoise.

First one being to slice the loop to individual instruments, the second one using the 9xx command and what i’ve heard of is that some people slice their beats to samples inside an instrument so that different keys play different drums. even though i do not know anyone personally who does this - i can imagine that it is being an essential part of tracking for them and that they must be really grown into it. So, when adding this kind of feature it is really important to make sure, it is versatile in a way that it meets the needs of everyone using it. Also it is important that none of the thecniques lose any of their benefits when used in with a new feature. It would solve on of these “working methodical barriers” when implementing this tool, if Renoise understood the instruments child clips as its children regardless of wheter they are held within the instrument or outside it.

That means if you prefer using the samples inside the instrument you could also approach the editing this way:

(This would also allow the users to move the clips of the mothering sample freely around in the renoise slots.) I thinki this kind of functioning is essential because that way none of us had to learn any new working methods and could just choose the one we are most comfortable with - and enjoy the benefits of our favourite style of tracking evolved.

So now that the compatibility issues of the traditional slicing of beats and using samples inside this instrument are set aside, lets move on to the 9xx command …and see how that can be included.

The 9xx command and the slicer:

Renoise already understands the bars lenghts and corresponding hits on exact measures. As we know this is achieved with the command 9xx (thats 900 being the first hit of 16th of a bar, 910 being the second 16th, 920 the 3rd and so on…) As discussed earlier - to sync the loop - the user would only have to tell renoise the amount of bars inside the loop they are working on, which is just similar to preparing a loop thats to be tweked with the 9xx command. This similarity makes the 9xx command easy to implement so into this slicer-instrument.

As you can see we have 3 slices that are magnetized to hitpoints. Not to cripple the 9xx command this would require a little approach from the developer. Here is how it works: If a 9xx value is magnetized to a hitpoint, that would change its playback position inside the sample. In otherwords the 9xx corresponds to the 16th hits of the loop as it already does and magnetizing any 9xx point would not affect the positioning of the others, but you would still be able to change the starting position of a single 9xx hit.

Okay, that’s that… i do not really see any compatibility issues or anything why this could not be developed.

So, it looks like Renoise has a possibe future to become the only all-in-one swiss army master loopt tool of all loop mangling tools ever. I’d like to courage the developers to take these few steps further because coming to think of it, Renoise is the only software out here that has 95% of the features of the ultimate loop tool already implemented inside it…

And perhaps the ideas above might be the key to combine all the best sides of these features under one hood so that everyone could enjoybeing able to slice beats with a GUI that suits any tracking method without losing the benefits of different ways of tracking or anyone having to change their orientation… .

edit: whoops some typos…

phatmatik is not able to beatsync a loop to the tempo and I have yet to discover a functional free beatslicer-vst. Believe me, I looked hard.

oh i see your point now… i’m sorry, i was too radical, surely working with long samples takes me lots of effort… 029’s concept looks wonderful, respect. so, sorry again, this feature would be really needed, many people would find it highly useful, including me! it would also solve the problem where i’ve got for example loong eguitar solo and when i’m playing pattern2, i can’t hear it, i have to play it from the start. solution - just slice it a bit and voila :)

maybe slicing sample to multiple instruments in our case is
not a elegant

I use breakbeats also but I agree with bundeano on this one, but for another reason not spoken here and that is efficency.

You have all noticed that developertime is a really precious commodity, resulting in the rare realeases of renoise as it is.

It makes somewhat a difference because its partly squandering developertime on nuicanse problems.

A beatslicer, given the possibilities of slicing with offset command + the sample editor to QUICKLY chop up large cumbersome samples into manageable pieces, is akin to wasting your last water in the desert because youre kinda thirsty.

A really attractive feature would take no time to develop and be really useful to many.

There are other more important features and a beatslicer would rank really low because it has seemingly low value compared to the programming effort.

A finer grain offset like dBlue proposed has probably a much lower programming effort and would therefore rate higher. It would also have the added functionality of improved timestretching with the “stuttermethod”.