Macro Patterns

[nobuyuki]

Hello,

I discussed this request on IRC earlier today, when someone asked me to make image mockups to illustrate what I was attempting to explain.  Basically,  my request is a rather large one but I think would have a large pay-off for trackers willing to work in itp or mptm format -- I'd like to see the idea of macros implemented into MPT.

When I think of macros, normally I think of old chiptunes and music programming languages like MML,  only keeping with MPT's tradition of visually illustrating the concept in an easy, straightforward manner.  What inspired this idea specifically was the ability to change various properties of an instrument in FamiTracker, namely the duty cycle and arpeggio "envelopes" could be changed independently of other features.  

I thought it would be extremely useful to genericize this as macros rather than creating endless redundant bloat in the instruments tab with various envelopes.  By decoupling instruments and some more special properties into macros,  they can be re-used in other instruments, and I can think of many traditional demoscene tricks made much easier with them.

Here is a practical example of a possible implementation:



This is how a default macro would be associated with an instrument, if any.  In this mockup, I used a spin button, but it would probably be more appropriate to use a combo box (drop-down) with names and numbers of the macros, so it would be easier to choose macros by name (name examples: "-- None", "01: Guitar Strum", "02: five-note arpeggio", "03: Major chord", etc).  

The macro tab itself would look something like this:



Please ignore the fact I mostly ripped off the existing patterns window for consistency.  There shouldn't be any orders in the macros, since each macro should only consist of one pattern of variable length and only have as many rows / channels as necessary.  The very first thing that's different in the macros tab from patterns would be that the primary instrument is a pass-thru to whatever its parent instrument is.  I also toyed with the idea of having pass-thru offsets for multiple-sample instruments, but this may be overly complex and that level of decoupling may not be necessary in the majority of cases.  (I can mainly only think of using it for multiple-duty-cycle samples, dual instruments, etc.)  From here, the primary notes and effects are entered into the pattern macro.  Patterns can be imported or saved individually for re-use or redistribution.

Ideally, no effects in macros would have a global effect on the MOD.  Instead, their scope should be adjusted for the fact they're being used as a macro (for example, Vxx would translate to an instrument volume falloff, not the entire MOD getting quieter).  Similarly, the speed multiplier (Axx) would allow for fast trills and arpeggios "between rows" in the main patterns window not normally possible at the default speed without unnecessarily expanding patterns to fit these notes otherwise.




Once macros are attached to instruments, playing the instrument in the normal patterns window should produce the sound from the associated macro transposed to the note in the main patterns window.  All effects in the main pattern window would override the macro on a global level, for example making a chord from a single string sample in a macro, and using the "string popping" trick common in oldschool mods and doskpop tunes.

If there is still letter space internally for mapping a new effect, I would propose something like \xx to switch an instrument's macro on the channel level.  The override could behave similarly to other instrument control effect extensions implemented into MPT -- allowing the musician to change an instrument to a duet or trio for example on the fly,  or adding a "fake echo" / delay effect from the macro.

Hmm, this request would probably take a lot of overhead and possibly new logic in the replayer to be implemented, but I sure would use it a lot if it ever did get implemented  

[Harbinger]

My first reaction was, "what do we need those for?" and you answered it. I could definitely make use of "one-touch" arpeggios, and i can see the potential of VSTi "knob-turning."

My initial concern would be syncing with the MPT's timer. After all, automated arpeggiation isn't any good if you can't stay on beat. Plus, i'm sure if this was worked on, they'd probably put it into the .mptm structure.

Implementation, however, would require something that i'm not sure our devs are up to, or have the time for: wholesale code creation. Right now they're inserting little snippets of code to a tightly-bound code structure, and able to make functional though simple tweaks (relative to what you're suggesting). Macro's would be useful for sure, but are going to require a lot attention, and i'm sure a lot of insertion points into existing code.

The devs of course can speak from themselves, but i guess all i'm saying is, even though it's a good idea, don't get any hopes up. After all we've been waiting for some GUI improvements that are not that easy to come by. :wink:

[nobuyuki]

The speed would be ideally based on a tick multiplier based off the original speed.  I don't know how MPT does timings anymore but essentially it would be locked to the original tempo with only a speed multiplier being configurable.  The replayer wouldn't "bake" the sound in a macro, but rather reproduce the sounds as if the mod itself was being played at a higher resolution with the notes in between rows according to whatever tick rate it's at by transposing the notes in the macro individually.  (sorry for not being clear on that, it's like 3am and I'm not exactly really clear on the tracker terminology for its internal timing)


AS FOR GUI IMPROVEMENTS,  hmm a friend of mine was messing with the gui earlier today and sounded like he made a lot of progress in a short period of time, but you didn't hear that from me   :lol:

[Skaven]

Sounds like a useful feature, I've been thinking about something like this too. But another issue that may turn this into a can of worms is its compatibility with .IT and .XM. I don't think I'd be able to use these macros in game music, as FMOD / BASS wouldn't support them.

But they would be pretty groovy still.

[Saga Musix]

Well, I'd just implement them for MPTM and when converting to another format, they'd be resolved automatically... or just add some kind of "transparent" support for XM/IT.

[Christofori]

Well, I'd just implement them for MPTM and when converting to another format, they'd be resolved automatically... or just add some kind of "transparent" support for XM/IT.

You have a knack for making everything sound easy... when you want to..!