man, don’t worry about it. it was definite because i was pretty sure this needed to be implemented natively and it would not be possible through scripting. however, my being sure was born from a lack of knowledge about scripting in Renoise, and of course not being able to predict the things your mind conjures up.
actually, i was never that enthusiastic about the whole clip-idea, but seeing it proposed here, i kinda like it.
aaah! (=
i thought about this… just like functions in a programming language. one definition and it can be called n times from anywhere. also, i’d say it is the logical extension of the fact that blocks in the pattern matrix can be “linked”. i have a little question (maybe i’m slow and this is obvious by your description) but anyway here goes:
does one set the pattern slot to have the property “copy any changes to my content to these other slots” or will it be on a pattern basis?
edit: ok, i guess it’s on a “pattern level”
I guess it’s supposed to be on a slot basis (a slot being a square in the matrix). Otherwise, it wouldn’t be as flexible. You should be able to synchronize slots “sideways” as well as “vertically” (or in other words, paste the clip anywhere)
The point being, that no single slot is the “original clip”. They are ALL instances of the clip, and the clip definition change each time you enter a note inside a slot which has been tagged. The closest thing you would get to an “original clip” is that the definition is maintained in the PMClip dialog (the list of clips).
About clips,
what I would like to see - possibility to make clips from all components for provided range of pattern.
Which means…
For example we have pattern with 170BPM with 12TPB. Length of it is 96.
I would like to aggregate all pattern effects with automatizations in range 0 - 47 and propagate it like trough the track in way how Control P is working.
Now it is bit annoying - synchronisation automatizations with pattern effect / notes is a bit time cost…
Personally I think I would find this method of incorporating Clips too limiting and not enough of an advancement on the Matrix for me to use it, but nice to hear you are working on it. What is really needed within Renoise is a way to have separate clips for different section (Notes, Automation, Pattern Commands) the ability to have more than one Clip per block, so chord progression and drum fills can be created by layering Note clips, Automation possible to be separated or combined for multiple parameters, and the ability to have clips of different lengths, overlapping and starting at arbitrary points compared to the other clips.
But that is really a full Arranger redesign, as discussed a few times to one extent or another, and I do think there are probably many people who might find your tool useful so don’t let me put you off.
yes, makes sense ofc.
ok! working with slots sounds better since the patterns that you want to try out different versions of are in general meant to be played back at certain fixed times in the arrangement. also, it would be grand just to drag and drop different patterns in the slot to see what it sounds like.
resurrection because of my own idea, which, as kazakore correctly points out, seems quite similar. https://forum.renoise.com/t/idea-command-groups/33148
danoise, i’ve tried my hand at this and it is just too much for a newbie scripting exercise. how are you coming along on this one, if at all?
Danoise, I would save clips as instruments (Preappend “Clip:”) with a custom data format in a ‘sample’, as I prefer clips per song. This would include the clips pattern data (saved from block with keybinding, but marked block coordinates are not even available via LUA iirc) and pointers to all insertions of the clip for fast updating. Sorry to say there would be no way of showing where a clip is being used in the actual pattern editor, which makes it even worse.
Making a project like this requires enough ugly workarounds to be useful that you probably wanted to wait for better native arrangment instead?
Interesting idea, using samples as data containers. Have anyone done this already? If not, I guess lua’s serialize methods be useful here?
Not really - the initial idea is actually completely transparent, at least to my personal workflow. What’s ugly about it is that there’s little tolerance for matching elements that are not completely identical - I really want to see a more intelligent (‘search-engine-like’) way of matching content.
Problem with most ‘clip’ implementations is that you need to adapt to them, instead of the other way around.
Oh, ok. Well, with the sample as data container you could keep track of where the clip are being used which would be very fast. Clips could be both inserted and referenced, where alteration of any reference affects the others. There should also be an option to “unreference” a usage of a clip and make it revert to normal pattern data.
I prefer this approach to a custom made pattern editor, and it wouldn’t need a search engine. The main drawback is that there are no graphical indications in the pattern editor of where clips are being used, but that’s a problem with Renoise.
I don’t know about lua serialization but I encountered some library with “dump” in its name that could handle objects, tables et c. It would probably also need a header with pointers. Maybe there are more standardized ways of doing this with lua.
I’ve not stored data in the actual sample data, but I have stored data in a simple format for the ReSynth tool in the sample name.
Storing data within the sample may be interesting as read/write to/from Lua is a float value from -1 to +1. Might be best to lower the sample bitdepth to 8 bit, enumerate all 256 possible values and use a simple conversion table of 'byte value ↔ equivalent float value. Don’t want to save this data in a lossy format though!
Maybe an easier alternative would be to use the APIs renoise.Document class and store data as XML files. It could also be integrated into the native file browser somehow for importing?
this seems like a good idea, because then clips could be moved around between songs and distributed
but maybe a less advanced clip functionality could be scripted for a start, something like EPMClip, “Even Poorer Man’s Clip” 
because there seems to me that maybe it’s possible to use the unknown renoise commands Cxxx and Exxx as clip markers (where the clip begins and where it ends) and then attach a number id to the clip
for example:
C-4 00 40 80 E001
[more notes and fx data goes here]
-- -- -- -- E001
everything between the effect column tags E001 and E001 would define EPMClip number 1 (and everything between E303 and E303 would define the 303’th EPMClip’s contents, etc)
since we have a maximum of 8 different effect columns in renoise, there’s plenty of room for other (known) effect commands
then in the pattern editor we could place out another effect marker that is unknown to renoise (but would be known to the script of course):
-- -- -- -- C001
this would place out the contents of EPMClip number 1 in the pattern editor whenever we called a keybinded function clips2pattern()
the script would naturally look for all instances of C001 in the current renoise song and then replace all matches with clip content data (which in this case is the data found between the first pair of E001 markers)
upon this replacement, the effect column clip marker C001 would be placed out by the script in order to keep the position tied to EPMClip 1
(because otherwise the poor man wouldn’t be able to assign new contents in EPMClips and have them automatically changed across the entire song)
if the poor man wanted to make EPMClips static (for example if he would like to assign that clip range to a new clip), he would simply delete the C001 marker manually in the pattern editor to exclude it from clips2pattern() iteration
and since the script would look for the first pair of Exxx in the tree, one could also manually delete the first Exxx and place it out beneth the second Exxx to make an alternative clip (assuming there is note data below the second Exxx marker), something like a clip stack
i don’t know enough lua yet so i can’t estimate how easy or difficult this would be to script, but maybe taktik’s find & replace script code could be adapted for the global find & replace procedures
storing clips in XML files would be pretty cool. you could have your own ‘clip archive’ with useful stuff.
So you’re basically talking about a version of PMClip without the pattern-matching, and with a couple of special commands for controlling the extent of a clip / where data is written to?
I like the idea, creating the basic user interface + the clip data managerment / categorization is one hell of a task, but this would be a good starting point and something you could expand upon.
Sorry I haven’t reread the thread (at the work, been quite stressed and had a headache so not going to before replying, sorry) but I always imagined it was a bit more like a Clipboard Manager.
Clips are chunks of Renoise Song XML Data.
They can be stored, recalled, named, searched, organised etc as you want.
As soon as you enter a PMClip on a song it then becomes part of the standard Song Data and can be edited and adjusted as desired.
To enable easy polyrhythms (one of the things I want Clips introduced to help with) would be Past Continous options for Selection In Patter and Selection In Matrix/Sequence. Then when you have the main of a song selected in Sequence Editor (written with a steady 4/4 beat and 64line for eg) then past a 3/4 or 7/4 beat over the middle section you don’t need to work out the different starting places for each pattern. Although this idea is kinda more another tool which should be available, as well as intergrated.
Although something more advanced (and preferably integrated) would be even nicer 
danoise,
Feel free to view my suggestion from ideas&suggestions. Sensible Clips - Preparing For Arranger
yes, i’m basically talking about an approach that strips out the basic user interface + the clip data management/categorization in your PMClip concept
so, no advanced pattern-matching with line notifiers, only matching of oneline effect command directed clip instances wherever they can be found in the song by regular find and replace functions (as provided by taktik)
although it discards of the gui, management/categorization is still possible (but without text tags like “drumloop 1a”), like for example we could let the first number in the 3 digit row define a group category of clips:
-- -- -- ---- ---- EA99
so that every clip number following A is part of group category A
this is flexible and would fit nicely into the keyboard focused workflow while also being expandable with new functions for processing individual clips:
process(clip)
like for example process(‘EA99’) would find clip number EA99’s definition space in the song and then do something to it (transposing/randomizing/etc) which we could audition in isolation and then decide if we wanted to populate to all instances of CA99 in the song
also we could introduce masks in such process functions, so that for example only the velocity column values would get added in mix-paste mode or overwritten
nice, in a way it seems similar to my own suggestion (some posts up in this thread) although in my version there’s no mandatory naming of clips or any gui, instead you just define both the clip-space and the clip number id with an effect command, on the go, and then populate the song with clip references with another effect command
i’d prefer that kind of alpha-numeric keyboard focused non-gui workflow, but of course it’s also possible to create a gui for it (maybe with rotary knobs for rotary selection of clips within categories)
just one more thought
maybe the approach i suggested above could also enable something like ‘nested clips’:
we define a clip space which contain references to other clips
so whenever the script runs to paste out clip contained data into the patterns, it would glue many clips together as one clip
@kazakore: what you’re saying about the clipboard is similar to what vV commented on my similar thread: https://forum.renoise.com/t/idea-command-groups/33148
On a semi related note, I’ve been experimenting on saving clips as samples, requiring several tools and hacks for it to sync with the pattern editor, sample editor, automation editor…
I’m using a small 88 sample pulse to use both as a visual and audible marker.
I didn’t use the auto detect slice marker during the process because it was off a few samples for some reason, even at 100%.
the following “{##}” indicates a slice marker number in its current mutation…
1st master clip {9} = 16 beats, 9 divisions.
2nd sub clip {3} = 3 to end of 5 from the 9 divisions
gets further subdivided by 18.
3rd sub sub clip {4} = starting at 15 of 18 from the 2nd sub clip, to the end of 5 from the master 9 division clip, gets further subdivided by 18.
EDIT: lower your volume, the 88 sample pulse create frequencies above 20khz, i forgot to place a filter
EDIT: reWorded sample clip and sub clip explanations, its still probably confusing, hopefully the xrns can deter some of that confusion.