This one is an apparently popular request that I myself needed in order to have a convenient way of getting envelope and fx interpolation spread across multiple patterns (at least up to 512 lines, the max number a pattern can contain) as I requested here.
Below is a view of the dialog that shows up now when you select “Split”. I augmented It-Alien’s original code and did some performance improvements. However, it is still somewhat slow if you split a pattern into > 16 parts. Due to the size restriction on a pattern, this probably is not a big deal.
I have a couple questions, since this is my first tool contribution, but it is expanding on someone else’s. How do I go about distributing this without creating confusion or stepping on It-Alien’s toes? Should I upload it as a separate tool with the “plus” suffix? I have credited It-Alien in the manifest.xml appropriately.
I have attached it for your testing/consumption pleasure. Please give me feedback on anything you can think of. You can compare it to the original and see what I have added. I would like to eventually get this up on the Tools page.
bleego
Forgot to attach the file! Getting a bit delirious this evening.
UPDATE# 390493: I have attached the latest version (.93) of the splitter. It addresses the numerical ordering of the patterns that are created in the process of splitting. It is with this version that I have uploaded this to the tools section.
big ups indeed for the multiple pattern split option, though I also encounter strange behavior.
If I split a 64 length pattern containing 2 note events (for example 2x beatsynced apache loops on line 0 & line 32), into 4 parts; I expect one note event to be in the first line of the first pattern and one note event on the first line of the third pattern. Now every pattern gets a sample!
Thanks for the feedback, but what actually happens when you split your pattern? Does the second note disappear? Right now it’s only documented in code, but dividing a track with an odd number of lines or dividing a track an odd number of times will result in line/data loss as I am doing integer division.
[quote=“Jonas, post:3, topic:31146”]
Big up and THNX!!!
bug
after splitting
1672
Oh I see… and I understand the bug. A bit of the optimization I put in is skipping the need to copy empty note data if something exists above it.
I will upload a new attachment with a fix. It will slow it down some, so let me know if hangs Renoise. I will look into improving the optimization.
Hi, Jonas, please give me more details on pattern order. What the code does is duplicate the current row N-1 times. These appear below the current, and should be ordered correctly based on the structure of the original pattern.
If you are seeing behavior that doesn’t conform to this and are getting patterns split in a way that reorders note data, please show me some screen caps or PM additional details so I can fix it. I am hoping to get this fairly rock solid before I post to the Tools page. I will address performance improvements AFTER a stable version of this is finished. Thanks!
bleego
PS: Thanks for the suggestions and enhancement ideas. Please keep them coming. Not sure when I will get to them (I’m working on a cross pattern interpolater, which is a bit more daunting of a project), but I’d like to keep track of them for future updates.
I don’t mean a wrong ordering of notes/pattern content after splitting, but about the numbering in the ‘arranger’. Splitting a 64 length pattern in 4 automatically numbers the patterns in the arranger in the following order: 0, 3, 2, 1, while I expect it to be 0, 1, 2, 3.
Ahh! I see what you’re saying. I suppose I never really care too much about the actual numbering of my patterns (I tend to use the name column on the right side a bit more). I can address this for a future update. Thanks.
Yes, the new project is going to be a much bigger affair, I don’t expect to have much to share for a few weeks. Unless the interpolation algorithms in Renoise are accessible via the API, I’m going to have to rewrite all of them. I am thinking this may be to my advantage, though, as there are a lot of ways to improve upon the minimal “logarithmic” “linear” and “exponential” options for interpolating.
If you or anyone else is interested in collaborating, I have a good high level idea of what is needed and can break down some of the tasks.
Not exactly… I need to redefine functions for interpolating values between a start point and end point. For instance, if you want to interpolate a volume fade in Renoise, you select the volume column, supply a ‘00’ at the top, and ‘80’ (or whatever value you like) at the end of the column. Then you right click, and go to Column->Interpolate Linear, Logarithmic, Exponential. This will set all of the empty rows in between with values that gradually transition from the start point to the end point. Linear implies a linear transition, where the rate of change remains constant. Logarithmic applies a logarithmic change (a logarithmic curve) and exponential applies an exponential change. This is fantastic and quite powerful, but here is what I am planning:
Basic feature:
The ability to set start/end points in different patterns
The ability to choose how many lines at a time to interpolate (currently it places a value on every line, I will make this a config setting)
Flexibility in use: If start point is after end point, switch points and then interpolate. Interpolate column the cursor is located, or define a default, or define multiple columns in the config. If only an endpoint is defined, define first pattern line 1 as start point, etc.
Pie in the sky stuff (for post-v1 releases):
The ability to interpolate note values (this combined with custom interpolation functions below would potentially be a cool alternative to the arpeggiator)
The ability to tweak or supply custom functions for interpolation (not quite sure about the UI for this yet, but if I can get the below idea working this could be EXTREMELY powerful)
As part of the above, possibly integrate UI for defining envelope automation as a way to define your interpolation function.
Defining multiple start, end points and saving them in a table so that you could apply on the fly updates to multiple patterns at a time by simply applying a keystroke, possibly in a live setting, or to ease song creation.
Ultimately this fixes a fundamental issue I have with Renoise: The automation envelopes and current selection functionality is tightly coupled to patterns. For a lot of what I do, envelope changes, fades, etc occur over many patterns and are often subtle. It is tedious to do manually calculate interpolation values for each block that I want to adjust. If the pattern length wasn’t limited to 512, then this would be a bit better since I could merge a LOT of patterns, make my envelope or interpolate a column, and then split them back up using the new splitter here.
I have a feeling a number of others would benefit from a feature like this, especially those who like higher LPB settings like 16.
This would definitely be a pie in the sky type feature, but yes, absolutely. This sort of thing goes under the programmable envelope idea for custom interpolation. Instead of setting the note values in the column you would set them where you define your function for interpolation, or the envelope.
Once the basic feature is implemented, doing exactly what you have described above actually would not be hard to do, and could be added down road.
I think once I have the basic functionality down, I will come back here for enhancement suggestions, because I really like your idea above. But first thing’s first… gotta get the foundation laid down.
bleego
Edit: BTW, Jonas, I have fixed the weird pattern ordering issue you brought up with the pattern split. I will upload a newer version later tonight or tomorrow, and consider it a release candidate for the tools page.
Please don’t download the top file, grab the 2nd one I’ve posted. The original has a nasty bug that replicates note data in tracks with empty space. I’ve noticed more people grabbing the original file, and it’s very alpha/buggy. The one below it is better.
I will publish a semi-final version this week that fixes all major gripes.
