I don’t know if this is available in the scripting, but I saw someone mentioning it in a milky tracker request.
I was like damn, that’s a good idea!
here is the thread with much more detail from User:Joule
http://forums.modarchive.org/index.php?topic=2576.0
I know the use of function keys is not really available, but I know there is a bunch of key combos not being used.
With some trouble it would be able to create a macrosystem in LUA, but some actions would probably be very ackward to put into a recording mechanism when it comes to mouse selections and click actions. (notifiers are needed to capture these events if possible).
But i think a basic macro recording system based upon key-input is possible. One can route the keyboard input through a script back to Renoise and allow Renoise to continue processing the original actions assigned to those keys after having recorded the keycombo to an array.
It won’t be easy though and it is a wormcan openener.
Emacs like macros would be awesome. In that program a macro is a recorded set of keystrokes. So for example if you want to change instrument for a bunch of notes you would do this:
Hit record macro.
Jump to next note button.
Change the instrument.
Hit stop macro recording.
Now press replay macro repeatedly and the program jumps to next note and changes instrument automatically through the song.
Great for all kinds of repetitive tasks.
That’s me. Thanks 
What would be the use of such macros in Renoise though? I suggested them for milkytracker mainly because tracking delays is such a tedious task.
i think Cortex’s example is a good one to show how this might be useful for Renoise. i think that this would be best to have as a script instead of native (before that whole discussion fires up).
No. Cortext example is a recorded macro, not a “code macro” like i suggested?
Ah, i see the difference now. sorry. still, this could be useful, but i still think this should best be scripted.
Some necromancy just to say that I’m working on this and have completed most of it. Some error handling and details is still to be fixed. Posting here in case someone has some pre-release thoughts and suggestions.
The tool will be called “f(tracks)”. What you do is enter a function in the track title and the tracks pattern data will be generated by this function. Live, auto-generated while you are tracking. Moving a slot (of a referenced track) in the PM will make the function track update 100% correctly, and it seems very fast like it would be native.
I have made a bunch of relevant functions, but here are some of the simpler examples:
Example 1: "=track(1)" -- will make the track a perfect clone of track 1
Example 2: "=offset(4, track(1))" -- will make the track a clone of track 1, offset 4 lines (global, i e across pattern boundaries)
Example 3: "=remap(5, offset(4, track(1)))"
Example 4: "=overlay(track(1), track(2))" -- Will make the track a result of track 1 + track 2, track 1 having priority.
I chose to use the track name as the function container due to it being the least worst option (better than song comment).
Some uses:
The best and most flexible tool to do dubbing
The fastest way to automatically make tracked delays
Split the columns of a track into layers (separate tracks) that are clonable in the PM. For example, edit the delay column in just one patterntrack (alias mother) and it will update the destination track thru-out the whole song. – relevant functions for this task: stripnotes(), stripeffects(), overlay()
Use it either while tracking live (depending on the task, you might want to mute the source tracks if they contain notes) or eventually as a one-shot processing of a track.
Eventually the tool might go into the multi-line realm with chord classes and a more elaborate editor, potentially doing things like merging a chord track with an arp figure/rhythm.
Any further ideas or pointers are welcome!
Some technical details:
The function (track name) is basically executed as is (sandbox) with very slight pre-/appending, even though the user syntax is fairly simple. The tool is easily expandable with additional track functions. What it does behind the scenes:
Always knowing what tracks are function tracks
If a new function track is entered, hooks up line notifiers to all relevant source tracks. This is done by silently executing the function once (as a prototype), checking what the source tracks were.
If editing is done in a source track, relevant function tracks are executed for every { pos } from the line notifier.
Handling some special cases (aliases normally escapes the line notifier).
Logo attached 
What a hack! Love it!
I’d been thinking recently about where hide the code necessary for such a thing. Using the track title is ingenius.
Huge intelligent arp potential here.
Maybe don’t throw out the song comments idea yet, though. Storing code there might improve portability, future-proof it, and would’t trash formatting (deleting newlines, I mean). Edit: What I mean is, if I understand correctly, the user could store the bulk of their generative algorithms in the song comments, and use terse fn calls in the track title.
Neato!
Edit: I hope I’m not completely misunderstanding what you’ve built, because now you’ve got me brainstorming, hah. Hopefully I’m not climbing the wrong hill.
The tool is easily expandable with additional track functions.
Like if you could “sync custom functions in song comments”, automatically or manually (into a block with unlikely delimiters like “~<{” “}>~”), then the tool would still work at some point down the road when your original custom functions have been sacrificed to the God Of Tech Rot.
Eventually the tool might go into the multi-line realm with chord classes and a more elaborate editor, potentially doing things like merging a chord track with an arp figure/rhythm.
Any further ideas or pointers are welcome!
Oh, I’ll chime in here and give some feedback as this seems to be a really cool anduseful toolnow cooking in the owen! If you’ll also crack the “Make Renoise into a Band-in-box or Chordpulse” path open, it’s going to make a big huge difference.
So, I don’t know if your upcoming tool is anywhere close to this proposed concept, but what would be really awesome IMO to have is an “Insert data tool” that essentiallylinks and imports the pattern XML data from external text files. You would launch the tool with a hotkey combo, a prompt shows up, you enter something and the script will import the data from the textfile with the same filename as something.That way we could build complex sets of data for e.g. chord progressions or whatever.
So for example if you wrote “Fsus4” at the prompt, the script would look for a textfile called “Fsus4.txt” (or just “Fsus4” without the .txt extension) and insert whatever is in that file into the pattern editor (at the cursor). You could then build further on that, grabbing for example an entire selection of contents spanning over multiple tracks, and then essentially have BIAB/Chordpulse styles n’ chord progressions imported as pattern data from the textfiles.
Youwould probably come up with a much more clever solution, but just to give you some ideas för att gnugga geniknölarna… 
What would be really awesome IMO to have is an “Insert data tool” that essentiallylinks and imports the pattern XML data from external text files"
Another place to store pattern data would be phrases. You could reinterpret phrases not as phrases but as arp patterns (I had a comment somewhere about how this could be encoded – I’ll try and dig it up), and f(tracks) could feed the parent data through the “phrase” (which is actually an arp pattern, with the sample number column instead representing the nth held note) to generate the child track’s data.
Thanks for feedbacking, guys!
Please don’t expect any chord functionality in the first version, though. Also, I don’t know how fast it would act when implementing a chord class so I can’t make any promises. Normal function tracks that only act per line reacts instantly.
I’ve been trying to look into cracking one of the korg style file formats, without success. Reverse engineering it seems really difficult. There are simpler arranger formats though (yamaha). The ultimate vision is to be able to interpret some of the arranger formats thru just track functions (and the mandatory guiding chord track, of course). That would be pretty awesome. This in conjunction with an extracted patterntrack library where you can quickly insert patterntracks from a database would make Renoise a unique bomb when it comes to rapid prototyping a song structure in a DAW. A vision, still!
Version 1 will be very fundamental compared to this, but after the first release has settled I’ll most likely start investigating the Yamaha format and how to make the chord class compatible enough to parse typical arranger data structure. The newer arrangers are probably too complex (Tyros 4…), but there are thousands of free styles in older formats that are still very useful and inspiring.
PS. I trust devs not to break the generous amount of data currently allowed in track names. Semi-colon can be used for “delimiting” lines in LUA, but if/when I make a multiline editor (like in xStream), I will probably have to do a simple one-shot conversion to song comments. LUA linebreaks don’t always mean the same thing.
PS2. Currently refactoring the code a bit to work properly with track aliases. Quite a bit of tiresome workarounds are needed to handle some of the “logistics” in Renoise and a special case like this.