I like pysj’s idea for the continuous mode only enabling when you select multiple patterns… perhaps the selection should be made with the pattern loop selection instead of the normal pattern selection however… I just wonder how it would handle duplicate patterns in that instance… would there be background colour coding to warn the user that changing the current pattern block will affect other blocks in the current selection?
As for the clips, I’m still waiting for this to be broken off into a separate thread but I’ll say this much: I very much want to be able to change the pitch and tempo of the clips nondestructively… an “instrument pattern” would do this… would your proposed idea allow that too pysj?
Glad to hear that the default pattern add functionality is changing… I constantly wish it would add a new blank pattern instead of just adding the same pattern number again.
As for marty’s subtick possibilities, I’m going with #3… simply because I don’t see a reason to limit the engine because Renoise stemmed from old software. We can still have perfect timing whilst also having floating point precision. Even if we go with the limited tick zoom, we could store the data in a less spreadsheetlike manner.
As for ticks, I don’t see a reason to abolish them when going for more resolution. Ticks can still be used as a measure of dividing a note, so as to keep tracker commands working. We could simply have a new default mode where the ticks don’t affect the speed of the song at all, and a legacy mode where they do. (stored in the song options of course) … something tells me we might have something similar right now, but I’ve never checked into it … either way, my thoughts still stand.
That could be… It’s a little less flexible, but perhaps easier understandable?
I guess if the block-loop would also change according to this ‘fake’ pattern length, then that should work too I guess.
I suggested that it should. Especially if we also involve clips into this. I suggested a ‘link’ symbol in the header of the track. But that is perhaps not enough? What if that symbol became red when in edit mode?
Yes indeed, but that would be an entire new feature. This would then be done in the instrument it self (called instrument-patterns).
So by default you can not do this. Clips are just blocks of data (like the multi clipboard you have in renoise now). When you insert a clip in the pattern editor, you will see all the raw data. To threat it as an independent clip that have properties like an instrument, you do that in the instrument itself.
You will then not see the raw data of the clip in the pattern editor, just a note from the instrument. To edit this clip you do that inside the instrument in it’s own clip/pattern editor).
You can of course easily drag/drop clips from the clip list into a instrument in the instrument list.
You could have functions like converting a selection in the patterneditor to instrument-pattern:
A new instrument was made containing the data from the selection, then the data was replaced by a instrument note.
So doing this we can have both ways. But they are totally different features really.
Let me also point out that we could have advanced options like add a normal clip to the keyboard directly as well (monophonic). So when this function is on, and you press a key on your keyboard, then you will hear the clip transposed. But the difference is that you insert the raw data into the pattern editor, and not a single note. This data is raw and do not have other instrument properties though:
Pressing D-4 in this mode would insert the raw clip transposed to D-4 (using my first clip example will become):
No, I don’t think so. When you enter ‘continuous mode’, you leave some things to be handled in the background (especially, taking care of auto-cloning patterns). It’s all about bridging the gap between how traditional, timeline-based sequencers work, and pattern-based ones like Renoise.
So, if you were to produce a very basic song with the same pattern repeated X number of times, all of these patterns together form a song, even if it’s just the same over and over again. If you then, like in my drag-drop animation, tried to move a selection from one pattern into another, the auto-clone logic would come into action, and produce the following result:
1: The pattern from which the notes were (re)moved is made unique
2: The pattern into which the notes were dragged (inserted) is made unique
3: The rest are left unaltered
This is about making Renoise (more) accessible to newcomers, and, at the same time, making the pattern editor capable of being an arranger as well.
So I’ve heard, and it’s a step in the right direction. As always, development is walking the thin line between intuition and efficient workflow
I’ve got an idea, inspired by how Photoshop work with ‘slices’. The problem with what you suggest is, that having all notes automatically converted into clips will produce A LOT of clips, making it hard to navigate. So, what if only the ones that were actually named/assigned a color would turn up as ‘registered’ clips? The rest would remain anonymous, and only appear in the pattern editor (perhaps as editable ‘gray’ blocks). I think that would solve the problem.
All I suggest is that clips are triggered via the pattern editor. However, clip ‘instrument’ numbers are kept separate from ‘real’ instrument number - so the clip note C#4 would not be the same as the instrument note C#4 (and you would always know, because of the visual appearance, shaded background etc.)
And since any clip ‘trigger-note’ has such importance (it will determine the clip playback sequence and/or basenote), it should be the one exposed in the pattern editor, not the embedded notes in the clip. I’m guessing that for an average workflow, the actual contents of the clip isn’t modified very often (which is why it was made into a clip by the user in the first place!).
A separate editor, visible alongside the pattern editor, would also make it really easy to select & modify clips while being zoomed out.
It’s simple - if clips are inserted into patterns just like instruments, advanced edit could be used to remap, transpose, etc. Basically anything that it has to offer.
To be honest, I’d rather see an option to ‘actually’ merge patterns together with a total length exceeding the current limit of 512 lines.
I think that is kinda drastic that Renoise will automatically do this. I guess I could live with a first time dialog for the behavior. But my point is that from now on you must active make duplicated patterns. As most newcomers will now clone patterns instead of duplicating them.
I would find it disturbing that renoise make them unique when I intentionally made it so it would not do that (because that is why I would duplicate patterns in the first place!). It’s two totally different ways of thinking. And so it should continue to be IMO). But this is nothing I would make big objections about…
Let me point out that when you enter some data in an empty track, then there will automatically be made a clip that is one pattern long (default, but configurable).
Yes, this will make a lot of clips, but this has to do with backward compatibility of the current workflow in a tracker. You should not be forced to make clips. You should be able to just start entering notes in the empty pattern as you do now and never even think of that there is something like clips there.
But you just came up with the answer for it. It’s all about hiding clips in the list (and visually by just adjusting the default clip color to the background if you like that…).
You actually quoted me from my first post in the Arranger thread from 2003 :
I then proposed to sort and filter clips by how they was made/defined:
I have also written tons of things about this internally in more recent times. I should really post some of this public now…
And here we need to separate things a bit to clearly make the difference in concepts for other ppl reading this.
You will not allow someone to see the content of two or more clips at once. Right? Because you have to open each clip in a clip editor. While in my concept this is possible as you can edit clips directly in the pattern editor.
Thats the main difference we have. I say that instead you can edit clips directly in pattern editor. They are then not threated with instrument properties, just raw extracted data. But you can optionally embed the data into an instrument. And this make this into two different features really.
That said, I would not mind a split patterneditor (that would be the same as your clip editor), and arranger view. So highlighting a clip would show you the data in another part of the screen.
I also (as written on one of my concept pictures) suggested that you could see focused clips graphically in the lower panel. It make sense to also be able to see it pattern style like your clip editor.
In general I think renoise should be more flexible to split screens like this.
Ok, that should be there of course.
Me too. I don’t understand the 512 limit.
But I find myself often wanna temporary merge 2 or 4 patterns (to for instance play a complete part of the song in one go), and also edit as one big pattern, but after I’m finished it would be divided back into my originally smaller patterns. My suggestion would allow that. And your suggestion would still be valid when there is no/all selection made in teh pattern sequencer(?)…
So if patterns are clips… and patterns can contain clips… then does that mean clips can contain clips? … and if that’s the case… what happens when you’ve got a clip which which contains a clip using an instrument that is linked to the first clip?
… also, would we clips have their own DSP chains, or would they be entirely dependant on the pattern’s DSP chain?
What about clip instruments… if instruments end up with their own DSP chains, will each track in the clip have its own DSP chain inside that instrument?
… or would we just get proper effect routing after all?!
Patterns are clips? Ok I know the terminology here can confuse ppl.
My definitions based on ‘my’ concept:
Pattern = the pattern we have in renoise right now, nothing new, nothing different.
Clip = a block of data. The same block you get if you in Renoise v.1.9.1 mark a block and copy it. Then you have a clip of data stored n the your computer clipboard. You can then store this clip in a clip list.
Instrument-pattern = independent pattern that only exist in that instrument. No clips inside the instrument-patterns. The instrument you use in the instrument-pattern is usually instrument only existing inside the same instrument. Because you can now have instruments inside instruments. But they are independent instruments. I’m not sure if we should allow instrument-patterns type of instrument as sub-instrument inside another instrument. In any case you will not be allowed to point to the same instrument creating a loop.
The other type of instrument allowed in the instrument-pattern is to point to instrument outside it self.
Again, you can not point to itself and creating a ‘midi loop’.
Clips are dependent of the pattern DSP. Instrument-patterns are not.
(however I would like that single-data clips like a wave-clip in a audio track could have at least some basic independent DSP like vol/pan envelopes. But for just normal clips you would not have DSP’s directly on them (we could make it possible, but dunno if that is needed when you can just make a instrument-pattern of it instead)).
Clip instrument I guess is what I refer to as instrument-patterns then? Then yes. Every renoise instrument would have a Master Instrument DSP track, and Instrument send DSP track. But also the instrument would have normal track/master/send for each instrument-pattern it contains (each instrument can have several instrument-patterns inside it self.
You can for instance map 5 different patterns on the same key only changing by the velocity you use in that key. Each pattern can have independent instruments, or shared instruments.
When using shared instruments, then you can edit many instrument-patterns at once!
On this picture you see how that works. You can edit one single pattern, or edit all at once from the range you make in the keymapper.
I have explained all this to great detail in the RNI future thread.
BTW, one problem not discussed in that thread, but I have discussed with taktik internally, is how the instrument DSP should work. If each note you play from a instrument having instrument DSP should be true polyphonic (calculate the added DSP’s for each note, or for all notes together). Normal samplebased instruments using only internal Renoise DSP would have no problem doing polyphonic DSP. But you are in trouble using vst(i).
Part of the solution to this is to have send channels inside the instrument, and to have option for internal DSP’s to be polyphonic or not. Then it is up to the user to build a true polyphonic instrument or a partly polyphonic instrument (like vsti are… you can only use vst’s on a single track… you can’t manipulate each single note from a vsti like you can from the internal sampler in renoise).
But you see… now this go way of topic. This really belongs to the RNI threads. But Danoise have tried to integrate instruments and clips… so thats what make all this seem a bit messy now
Edit: Hey pysj, I’m a slow poster - didn’t see your reply before now. Lets try and keep the focus
Recursiveness… that’s tricky stuff. But I’d say that a clip could hold any instrument or clips, except (any of) the “parent” clip(s). Then we would avoid clips that reference themselves. And BTW: I don’t mix patterns with clips! In my book, clips are only able to hold whatever a track can hold (I’ll explain below)
I have no “clip instruments”, just clips. Clips can contain what I call “dynamic clip parameters”. It makes them able to adapt (reconfigure) themselves to different track-DSP configurations using existing DSP devices, with a minimum of GUI space. But basically, putting a clip into a track will make use of the available note columns and DSP devices, just like a any normal track would be able to.
Before you think “hell, this is not ambitious enough for a such an amazing thing as clips!”, think about how clips can be created from existing notes, and should also be able to convert back into normal notes. Part of the problem would be, that if we were to define some fancy concept for a clip including a separate DSP chain, there would be no (simple) way of converting such a clip back into a normal sequence of notes.
I really think this is best dealt by improving the xrni structure, which has a lot of potential for separate DSP chains, routing etc.
I’ve not suggested a single change to instruments (yet). Instruments are instruments, no change at all. All clips and instruments have in common is how they are dealt with (entered into the pattern editor!)
But hey, I was confused by your ideas as well, especially the instrument part (referencing other instruments?) - it’s funny how I should point to the xrni future thread too;-)
But you have given clips instrument properties! right?
Well, anyways. If your ambition is that you can convert all embedded instrument data into raw extracted pattern data then you are in real trouble. You just mentioned the DSP problem. But the other thing is what if I have many different instrument patterns (or embedded clips you would call that?) and play a chord. Lets say each instrument-pattern have 4 tracks, and DSP’s and automation devices and what not, how will you possible be able to extract that data into a single track in the pattern editor?
Thats why I have tried to keep a clear difference between what a clip can do and what a instrument-pattern can do. I just can’t see your concept work in a consistent way. At least not with quite fundamental limitations like not being able to edit the content of several clips at once, side by side in the pattern editor. And also how that all would be backward compatible with the current pattern sequencer etc.
But I may have got something fundamental wrong about your concept here
We are not far away from each other, but I actually am not 100% sure what your definition of a clip really is.
What will I see if I drag and drop a clip from whatever list you have that clip in, into the pattern editor?
Will i see a note representing that clip (like on your flash where you see the external clip editor side by side of the pattern editor) or will I see the extracted data (the real content of that clip)??
Ok… taking into account that I’m pretty sure the clip idea stemmed from the need to have some sort of non-destructive arranger concept…
I have one question: if you have a clip, followed by a few non-clip notes… and you zoom out to arranger view… and decide to move the clip down a bit… what happens to those stray notes? are they automatically going to form a clip of their own? will they exist under the clip you just moved on top of them? Will they simply disappear? What are the exact rules for these sort of circumstances?
There is no such thing as notes that do not belong to a clip.
If you enter any note in an empty space in the pattern editor then there will be created a clip automatically.
The size of this automatically made clip will be one pattern length by default. If there already is a clip occupying half the pattern length, then a new clip that covers the other half of the pattern length will automatically be created.
Clips can not overlap. Just the same way that you can not copy/paste a block today several times upon each other. Then you just overwrite. But any clips that overlap another clip will not destroy the clip(s) underneath it. It’s still there if you remove the top clip, but you can only hear the one on top.
In other words you resize and overlap clips nondestructively. But only the visible clip will be valid. No hidden data in there.
With a modifier key you can resize a clip destructively over it’s original size (and you can of course merge and split clips destructively as well).
If you want clips that behave totally independent, then you use the instrument-pattern instead. Then you can trigger anything like you want, but you only see the patterns you trigger as a single note(s). To edit these instrument patterns you do that in a separate editor that is connected to the RNI structure, and not in the main pattern editor where you only deal with clips.
You see the difference between clips and instrument-patterns?
I guess I’m just kinda confused as to how the nondestructiveness would be displayed in a pattern if in the arranger, you moved another clip on top of the pattern-long clip for instance.
In the pattern editor you would not see clips at all (or we could use color coding or a ‘frame’ to indicate where the clip start/end, but in principle you would not have to know there even exist clips at all if you just wanna track the old school way). In my concept you deal with clips only in the arranger mostly (although I see no problem also doing some basic clip resize/split/merge things directly in the pattern editor as well). How small clips do you think you normally will use anyway? How many lines? I see clips as something you would use mostly 1 pattern length in size or more, then some linked clips (duplicated clips) could be useful for half/quarter pattern lengths to quickly set up some beats or baselines etc, and in a very few cases down to 8 lines? So how much information about clips size and boundaries would you find useful in the pattern editor if you had an separate clip-arranger window? I’m not sure…
To edit the frame of clips destructively you could either do that in a separate clip editor (graphical as I have suggested, but why not also pattern editor like one).
But anything you do in the clip-arranger is not destructively by default. If you delete a clip there, then the clip is not gone, it is still in the clip-list. If you however delete something from the clip-list then it is gone for ever (although we could have a function to directly destroy the clip in the arranger using shift+delete for instance, delete from arranger and project).
So lets say you have a clip that is one pattern long, then you drag/drop another clip that is half the pattern length that overlap the first clip, then we have two ways we could deal with that, either the underlaying clip will be nondestructively deleted under the overlapping part. So if you then remove the second clip, then you must manually resize the first clip to its full length again (if you wanna use the full length of it right there). But no matter what if you drag/drop another instance of the first clip into some other part of the song, then of course the entire real length of the clip (1 pattern length) will be added. = nondestructive.
The second way is that if you delete the second clip the arranger, then you will see the previous state of the first clip (the entire size of it, no need to manually resize it again).
I’m not worried about this at all. It’s in the clip list the real data is stored. As long as you don’t delete things there, you will never loose any of your data. No matter how you overlap clips in the arranger…
Also remember that we are not just dealing with note clips. There would also be audio clips (streamed in audio tracks), automation clips, and perhaps even fx-data clips. And that is also why I think the separate clip-arranger might be the better solution…
Ah good… the what is a clip discussion
Let’s be consistent. I’ll call my idea of a clip a “note-clip” from now on
First of all, no arranger features without clips. I imagine note-clip as a pretty clean-cut separation from other elements in Renoise. It’s neither a pattern, track, nor instrument. It’s made from pattern data, along with some additional space for automation curves and mappings, which can then be linked to the “main pattern” track DSP’s in a dynamic fashion, to control whatever effect that we might prefer it to.
The secondary editor is in essence a small version of the pattern editor, containing a single track worth of pattern-data, as well as options for controlling automation curves.
So, with note-clips, no audio processing is taking place, it’s made from simple note/controller data and mappings.
I’d say, let’s expand the track itself Current limit is twelve note-columns, with a larger limit, that wouldn’t be a problem. As for DSP automation, note-clip parameters are already linked to actual, existing devices, so that wouldn’t be a problem either.
If you decided to drag a note-clip into a busy track in the pattern editor, what you would see was perhaps a track which previously had one, unregistered clip, make room for the new clip, or have the new clip “float” on top of it (we largely agree on the idea of “unregistered” clips, and how they work). As for clip content visibility: it depends.
Standard arranger features, the kind of stuff you need a mouse for
This is where we disagree the most. I’d say, let’s work directly with clip trigger-notes, as the default editing mode. You are saying, let’s keep all notes available at all times (except for “instrument-clips”), if I understand you correcly.
But perhaps we could come up with a solution, an automatic toggle for displaying clip contents. Imagine when you’ve opened the clip-editor, clips in the main pattern are displayed as trigger-notes. When closed, these clip instead display contents as a (editable) note sequence. That’s the best of both worlds.
Thanks for explaining that. You think as I thought you did Just needed it confirmed.
About if you see the clip content in the main pattern editor or not:
Bingo That is the difference I have tried to point out all the time here.
And I see huge problems when:
That is not as easy as it sounds. In an ideal world we would have independent clips that can have it’s own tempo and devices and so on. I wanna restrict that to what I call instrument-patterns. What I define as clips can not do this. Thus you can not extract/convert the content in the main pattern editor like you want.
You on the other hand want to treat all clips as instrument-clips where you toggle between to see the note trigger or to see the content of the clip directly in the main pattern editor.
That can work to some degree if we give heavy restrictions like no independent tempo and perhaps how many tracks it will be able to use (one track clips only?).
However, what I have suggested with instrumnet-patterns is that you can actually map several entire patterns into a keymapper in the instrument. You can in principle trigger as many entire patterns you want by just pressing a key on your keyboard. And they can all have different length, different tempo, different dsp, different and independent instruments, and even different sustain and loop settings. This would be totally chaos to try to convert any of this directly into the pattern editor. Also when you have transposed trigger notes, and then extract the clip, and then edit some content in there (still transposed) I feel the whole thing will just be messy
Another thing is that there will be a hell of a lot of clips. So will each clip then occupy a instrument slot?
If not, how will you then show the trigger note for the clip?
Don’t get me wrong. I also have thought a lot about your concept here. It was how I initially thought is could be many years ago. But after a while I changed my mind as it would be too messy and in some way restricted.
But right now it is not clear what we will end up with. It will probably not be far away from what we have discussed in here. But in the end it is up to taktik to decide as either way can be quite much to change to make this work (if we also include the RNI structure change in all this).
The advantage of what I have proposed here is that it does not need much extra restructuring to make a simple clip editor up and running. No trigger notes etc. Stuff like that could be saved later for the big upcoming RNI change. It’s just a clearer difference in how you do things, and clearer/easier to implant one thing at a time. IMO of course.
But time will show
Why not just make clips the same thing as patterns then? … that way you can arrange patterns however you want, side by side, whatever, just like this clip concept, except you could trim down the number of required tools, and confuse users a whole lot less? I don’t see one real benefit to defining a separate construct from patterns, looking at what you’ve mentioned here… these could all be changes to the current concept we have of a pattern… and it would overall make things a heck of a lot more flexible.
What do you mean you can edit several patterns side by side?
You must edit individual patterns right? what if one pattern has another tempo then the other? How would you visualize that?
A clip can contain a pattern, or many patterns by using instrument-patterns. Is that so confusing?
This was discussed in this thread many years ago. Probably many of the pictures in that thread are gone now…
I have read some of the posts in this thread - specifically the ones on the first page, and watched the demonstration flash videos.
The visualization is superb, and the ideas are quite nice, but I have some points I would like to mention.
My bulleted two cents:
I probably missed the description of the piano roll feature. I also do not understand what is it for, and am generally against piano rolls and everything they stand for. So unless there is a really good reason for adding one to Renoise, I would avoid it.
So, generally speaking I would say this:
I am +1 on the zoomable - if it will also provide a decent solution for songs with no clips.
I am +1 on clips - if I can keep doing songs naturally and nicely without them
I am -1 on making the continuous edit so it will automatically clone patterns, but it will not bother me if this is a configurable feature (i.e. i can stay with the current behavior)
I am -1 on the piano roll - unless there is an explanation for it.
The bottom line - since the people who designed renoise so far seem to have done an unbelievably amazing job, I trust they will continue doing so with or without my comments so whatever is decided is probably gonna be excellent.
The short version of this post is: Keep Renoise a tracker.
I respect your opinions. I really do!
But to me it seems you just comment on something you do not have the fully picture of. So you naturally get a bit worried if this is all bullshit that you will never use?
Let me put it this way:
Should we remove the mixer? Or what about the automation window?
And, do anyone really use vst and vsti’s?
Lets get rid of that bloated stuff…
We should just keep it a tracker, right?
Of course anything that will be considered added to renoise has to go through a longer process of discussing. Then a alpha team will evaluate the thing, before even more finetuning in betas. If anything feels wrong in any part of the process it will usually not make it to the program.
And backward-compatibility is not something taken easily among the team.
It’s confusing, because we still have separate ideas about what the clip contents is actually made from. It’s obvious that when you use the term ‘pattern’, everybody will think that it’s a full pattern with all features. Is this what you want? And how could a separate editor hold all this information (at least, in your screenshot, there’s not nearly enough room).
I’m suggesting that a clip can hold information that corresponds to a track, without a separate DSP chain. Instead, it relies on existing DSP effects to achieve per-track automation. This would keep things simple, and remove the processing overhead resulting from an extra audio layer (note/controller data only). I say, let the RNI Future instrument come with a DSP chain, built-in arpeggiator/sequencer or whatever. I would still want to be able to use clips in the way I’ve described.
I still think we can come up with something with regard to tempo. After all, we’re not talking BPM, just speed, right? So, in essence, all clips would be running at the same ‘tick’ tempo, it’s just a matter of supporting multiple notes & commands per tick, and clips could easily fit into a normal track, no matter how fast they were playing.
Apart from the DSP part, which I disagree with, I think that everything you suggest is possible. Why shouldn’t it be? The next screenshot I’ll make will depict a way to map note-sequences onto a keyboard.
I wouldn’t. Unregistered clips still show as editable content. After all, the most important reason that normal notes are automatically made into clips, is to provide a way to visualize them in an arranger. Once registered, they will show up in the “instrument table”, where you can assign name + color
And of course, there is a balance of what should be in and what not.
I did not mean keep it an eighties tracker, just a tracker.
You know when glorious pieces of software cease to be popular? when they get over bloated.
Back in the happy 90’s, when software companies realized their mistake, they released a “Lite” version of their software, hoping to fix the damage, but it was usually too late.
So, my only point is: be careful of over-doing. This is a traitorous ground.
Also my point, is that you have to decide who is your audience. You cannot make a software that will appeal to all audiences. Its too vast of an area.
Of course, no disrespect meant - I think the renoise designers are the SWAT unit of software design in this decade and they should be studied in the history books of our grand-grand-grandchildren…
… either way, my thoughts still stand.
:
