The MetaPads Project

[Raveshaper]

I just chewed my way through over 1200 lines of code over the course of two days.
I'm tired, but I think I finally got over the hurdle that was in my way.
This has been a gigaton of complex logic to mentally grasp.

I have been working on a project that I call MetaPads for nearly 9 months now that started as a template document I began designing for Mike (the fixr). Over time, it quickly became clear that using stock devices and CV was just too processor inefficient to get the job done. I began reverse engineering advanced surface codecs from Livid, Mackie, and Novation and eventually applied to become a Remote dev (and discovered I knew all but maybe three minor details already) before I really began making any significant progress.

The original intent was to increase the number of sample triggers that could be fit into one 4 x 4 pad controller, but it has since transformed into something highly ambitious that could very well shake up what is possible in R7+.

"Layered Pads"
The first thing I did was build layers inside of my pads so that eight key ranges of 16 notes could be played from one 4 x 4 page, as defined by the controller editor for the hardware. With multi-page controllers, this dramatically increases the number of triggers a controller can send. I'm personally using the Maschine Mk2 hardware, but the Korg padKONTROL and Akai MPC line should work just as well.

The layered system makes it possible to freestyle on the pads while adjusting through the layers using the jog wheel. This also allows for layering multiple sounds from different layers at the same time.

"TRAKT - R"?
The first thing I added beyond an expanded pad system was the ability to not only play audio clips and stems in the sequencer like a giant sampler, but also the ability to scrub through and define which regions of the timeline to play on the pads -- direct from the hardware using an intuitive edit mode.

I took this a step further and made it possible to define "loops" made up of between one and sixteen slices that are unique for each pad. The slices can be out of order with respect to elapsed time in the sequencer (left to right progression) and will continuously play through while the pad is held down.

"Plugin Mode"
I took this concept of triggering the sequence even further out by making it possible to control one Reason document from another using EMI so that the sequence-triggering behavior could be used as a form of "mega instrument" within an arrangement. Doing this requires a multi-channel audio interface in order to capture the output to an audio track, as well as latency compensation, but it is possible. At least in theory, I will be testing this surface heavily as soon as it's finished. Stay tuned for possible heartbreaking news that my efforts failed to make this possible (but I think it'll work just fine).

"HSB Support"
Since the illuminated pads of the Maschine Mk2 controller respond to HSB input, I included a system of HSB to give each virtual layer on each page of pads its own unique color. Just as a bit of a finishing touch.

"Memory Cartridge System"
Following a little bit of wizardry that I used heavily to brute force my way through reverse engineering in the beginning, I figured out a way to create a sort of memory recall capability that dumps the contents of all defined cue points on the timeline into a text file that can then be used to return to the surface back to that operating state at a later time.

This makes it possible to define a bunch of triggerable points, dump out the data to a text file, and then re-import it to avoid having to re-define it all over again (which would be a pain). Considering you can have up to 16 (pads) x 8 (layers) x 16 (slices per nested "loop") x 2 (start and end points) = 4096 worth of defined data, that's a universe of pain you shouldn't have to revisit.

"Expandability"
I designed this complex system around my other projects so that it can be used in combination with things like my Vinyl, SmartKnobs and Super Combinator scripts. I have an entire template constructed for the purpose of live performance that I plan to integrate with MetaPads and SmartKnobs to achieve unbelievable flexibility of control on stage.

For those who are unfamiliar, Vinyl is a script that uses a precise exponential function to manipulate the tempo of a song project to match the playback speed of pitch bent samples. This allows you to record the output to an audio track to achieve advanced pitch-shifting and octave warping without losing the original timing of the audio clip/sample.

SmartKnobs is a script I designed that allows you to use 4 x 4 pads as an addressing system for applying relative mode rotary manipulations to up to 16 different remote overrides per knob. Think of it like a remote override version of the splitter portion of a CV Spider. This allows a limited number of knobs to work like a massive bank of them.

The Super Combinator script is still very much just a basic shell, but it allows one device control to manipulate another device control directly without automation or the need for a Combinator. It uses EMI loopback of a fast rate LFO as a polling signal and essentially makes every type of control on the front of all device types communicate directly with each other in terms of (0 to 127) values. The remote override networks respond to automation clips, allowing for previously impossible levels of sound design and fine tuning of advanced patches.

"Choke Groups/Back End"
The way the surface is built, it has one instance for each midi channel from one to sixteen. There is a system intended for use with a specially designed portion of my template that allows me to choke individual layers as well as entire midi channels while I play. This makes it possible to mingle layers of sound up until the moment that all pads are released and the current layer selected is triggered by itself. This also makes it possible to switch to a different midi channel by selecting another page of pads on the controller and instantly silence the previous midi channel's sounds. This was a specific requirement that Mike had asked for.

"Keep it Simple, Stupid"
All of the advanced features are not required. It is possible to just play the freestyle pad system without using any other portion of the surface. It's up to you how much of the madness you want to get into.

This is still being constructed, I'm too exhausted right now to complete it and begin testing, but soon it should be ready to be thoroughly debugged.
Obviously, as such, it isn't available right now. But I'll be posting follow ups on the progress as and when. I wouldn't normally do this, but considering the severity of the project, I may seek to monetize my creation. It is, in essence, an expansion pack or soft patch for R7+.

I look forward to finishing this titan, more soon.

[Raveshaper]

Ok, so due to the complexity of this build, this will take a bit of time to finish.

I already have it in a stable enough condition that it won't throw errors, but unfortunately much of the logic needs to be re-factored to work correctly.

I probably would have gotten it right on the first pass with no hitch, but then this project is nearly 2100 lines of code. No wonder I goofed.

Stay tuned.

[MirEko]

God speed..

Look forward to seeing what this is like. Fair call to monetize it. Halfway through reading your post I was thinking "hope he doesn't just give this away"

[Raveshaper]

Putting in a lot of hours on the final build of Vinyl lately.

So far I've converted all note-to-pitch conversion calculations to lookup tables and eliminated the tempo automation dropout problem, but thanks to the ugly way multichannel midi recording currently works, I'm having to restructure some of it as I go.

One of the benefits Vinyl will have with respect to MetaPads is the ability to beat match playback. It is possible in concept to create a virtual set of turntables, in other words.

The short of it is, this will take some time. I'm pushing into unexplored territory here.
Thanks for your support and patience.

[eusti]

I honestly cannot figure out what this is really going to be, but am definitely curious! Best of luck!

D.

[Aquila]

Subscribed to this thread. This sounds like the closest we're going to get with advanced pad performances in Reason for now.

[Biolumin3sc3nt]

QwaizanG

I'm not sure of of everything you said, but I'm very excited! Keep on keeping on Sir!

[Raveshaper]

QwaizanG

I'm not sure of of everything you said, but I'm very excited! Keep on keeping on Sir!

Thank you, Bio. I certainly will.

I wanted to give a quick update about my progress, since some things have come to light that have changed the game a bit.

During testing and troubleshooting of the Vinyl script, I have encountered difficulties while handling data packets that are sent through MIDI loopback. I do not like making people wait longer, but I have thought about this and I have come to the conclusion that if I'm frustrated with how it's behaving, it would kill the usefulness of whatever I put on offer in the hands of anyone else. So, some delays will be involved in the short term.

Rather than use MIDI data over loopback, I will re-design my scripts to operate as reactive networks the same way my Super Combinator proof of concept does. Any data that would have gone over loopback will instead be handled internally.

I want to make it incredibly clear that my scripts will require specific remote override mappings and overall setup. Unfortunately, I can not create simple plug-n-play surfaces that "just work" with little fuss. As such, embarking on this path will require following instructions and has the potential of becoming a bit complex.

If you want an easy solution that just works immediately, this is not for you. Get Live instead.

If you want to perform live using Reason or want uncompromising capabilities of sound design, and you don't mind some maintenance to make it happen, stay tuned.

[Raveshaper]

Time for another update, this time with better news than the last.

I have successfully found a way to ditch having to use the EMI in my surface designs at all.
This means that all of the unexpected behavior I have been encountering so far can be eliminated and progress can move forward.

This does not mean, however, that new unexpected behavior will not be encountered in the future.
The bottom line is that there is one less thing for me to worry about.

I'm going to be working hard to re-factor my code to incorporate this major change, which means making my function calls as efficient as possible, so bear with me. I am also working on completing Vinyl, so I have my hands full.

Thank you all for the support and I look forward to unveiling this project when it's complete.

[Aquila]

That's good to hear. All the best

[Raveshaper]

Time for another short update.

I have finally triumphed over a major issue I was having with the polling rate of the scripts involved.
Now that this obstacle is out of my way, I can move on to refining the overall build.

It turns out that this project has hit the limits of execution time when it comes to a single complicated script. Basically, it runs too slowly if it is one beefy piece of code that does everything. This means I need to port each feature into its own script that can seamlessly run along side the other features and appear to operate as a single unit.

This is a PITA of sorts, but it has definite and obvious advantages. If you don't want or need a feature, you can choose to deactivate it or just not load it. This project might end up changing names by the time it's completely bug-tested, but this is a good working title for now.

The bulk of my time can now be spent porting code out to individual scripts and troubleshooting the choke group switching/slice programming routines.

This is going to be amazing stuff.
Once I have something to show off in a video, I'll definitely be posting one.

[MAL9000]

Am watching this with bated breath and great fascination. Can't wait to see what it looks like. In advance of any Beta testing you might need. Please feel free to add me.

[thala]

Am watching this with bated breath and great fascination. Can't wait to see what it looks like. In advance of any Beta testing you might need. Please feel free to add me.

same here. got a maschine mk2 and really would like to test this beast

[Raveshaper]

same here. got a maschine mk2 and really would like to test this beast

The most difficult part of this will be compatibility issues with different kinds of hardware. So, in your case testing would be a luxurious experience.

I am not able to work on this full time as I have said in the past, so I will simply have to put in more time around everything else in my schedule to get this finished soon.
(I'm getting impatient.)

This is evolving beyond a live performance system and becoming an expansion pack of sorts to the stock tool set of Reason. But mostly it's for performing and composing in a whole new way.

I'm going to really push to get this completed.
Once again, I want to thank all my supporters. I know that each of you will be doing incredible things with these innovations in your hands.
I'll see you all in the near future.

[grumo]

I'm also quietly observing in awe, bless those who have he patience to code!

Give me a shout if you want me to test it out with a padkontrol

[Raveshaper]

Oh boy, I really don't enjoy SysEx.
Times like these are what caffeine is for.

For those familiar with Maschine hardware, what this whole "super surface" level scripting does is expand the number of mappings by routing them to different places inside Reason based on toggled "modes" as defined by the scripts. What this means is that when a mode is toggled by a button for instance, you must then tab to the appropriate page of the display to see the feedback. This is not intuitive and a rather ugly way of implementing this. So now what I am having to do is reverse engineer a way to update control labels with custom strings, or brainstorm how best to present the information if that's impossible.

There is currently only one thread online that discusses how to achieve LCD feedback using SysEx on Maschine.
That's how far into the obscure this whole thing is reaching.

I am about to dive into a long haul of reverse engineering attempts to see if I can't unearth the secret to updating control labels.
If it fails, then on to plan B.

The way I planned this system to work is for each physical Maschine controller to tie into 8 midi channels each. The end result of successful LCD feedback via SysEx will be the possibility of mapping out all 8 midi channels to their own LCD pages.

I hope.

[thala]

have you seen MaschineR from retouch control? maybe contact him for some tips?
he is a quick responding and very helpful person.
just try...

[Raveshaper]

Good idea. Just sent him a note.

[Raveshaper]

Day jobs are seriously competing for my time right now, but work is progressing.
Wish I had more to say about it but that's the status.
Better some news than no news, but there should be more than this to talk about very soon.

[Raveshaper]

Progress Report: 29/09/2015

1. The logic of the choke group system has now been completed.
It now has the following features:

• Officially Named "Z-Triggers"
• 8 Sound Layers Per MIDI Channel
• Stackable/Sustainable Multi-layer Playback
• Calibrated Note Input (Preserve Transient Attacks)
• Supports 2,048 Samples at Once
• Dedicated Template With Kong-based Combi Patches

As before, you can freestyle up and down the layers as fast you can switch through them.
The major victory here is that you can now sustain triggered samples as you flip through layers and build up a stack of audio as you go, then release all pads and isolate the current audio layer at the moment of the next sample's trigger event. This was surprisingly challenging to accomplish.

The Note input calibration introduces a slight delay in responsiveness in favor of preserving the attack of transient samples during layer choking.
Without introducing some nominal latency, the choking was not capable of isolating sound layers fast enough to prevent trimming off the very first part of a transient's waveform. It is incredible to finally have this unwanted behavior corrected.

The maximum sample count supported across the entire 16 channel system is now a staggering 2,048. This is believed to be well beyond what Reason can load at any given time, but further stress tests must be run before this can be confirmed. In the event of a confirmation, the architecture will be updated to work around this limitation.

The template file was built to the specifications as defined by Mike/thefixr, but it can be replaced with instances of NN-XT to cut down on device count. Kongs have advantages over samplers in that they can utilize the Nurse Rex and drum emulators, adding more emphasis to why a proof of concept design was built around them. The patch design incorporates transpose of incoming notes to distribute 8 splits/zones across the entire keyrange of each Combi.

2. The system clock has been coded. It enables all scripts that share its assigned MIDI Port to respond to events intelligently at an approximately steady refresh rate of 1 ms. The clock signal can be toggled on and off.

This clock signal will be required to use the cue point system, the RackNode super combinator device network, and the Vinyl advanced resampling engine.

What's Next?

• Conquering the logic of the cue point system!
• Completely debugging Vinyl.
• Finishing MegaKnobs and SuperKnobs.
• Finishing Sysex Visual Feedback and Finetuning Live Performance Template.
• Diving Into Finishing RackNode.

RackNode will take the most work. That's why it's last on the list.
I want to make it as user-friendly as possible, despite being the most powerful upgrade to the rack since...the rack.
It's the project I'm most excited about, but until I get everything else out of the way, I can't skip ahead.
I will try to put together a proof of concept video for these designs soon so you can at least see what it is I'm talking about.
I don't have pro-level videography gear, but I can make something happen.
This is super exciting! And there's even more exciting stuff on the way!

[Raveshaper]

Progress Report: 30/09/2015

1. The core functionality of RackNode has been completed.
It now has the following features:

• Up to 128 channels of I/O per surface.
• Up to 128 channels of output per source control input.
• Blazing fast 1 millisecond data refresh rate (can be toggled on/off).
• Panic button to suspend/resume data traffic.
• Dedicated buttons for editing minimum and maximum values.
• Intuitive edit mode for setting min/max settings on the fly.
• Device networks respond to mouse edits, automation, CV, EMI, and MIDI hardware.

Ok, so I skipped ahead. I couldn't help it.

It is now possible to bind device controls together directly in the rack. The filter frequency of a Malstrom can now manipulate the attack of an amp envelope on a Subtractor, for instance. Or, both the Malstrom and Subtractor can have multiple knobs and faders under the control of a CV source sent over EMI. The possibilities are enormous.

In brief, what RackNode does is it allows devices of all kinds to speak directly to each other. Every knob can talk to every fader, and so on. Using networks of remote overrides that the user defines, those mappings can be made to communicate to each other, such that changes made to one device can cause changes in another. The initial device that receives manipulation is considered a source device, while all other devices that receive manipulations as a result of changes on a source device are considered destination devices.

It is now possible to intuitively adjust minimum and maximum ranges for all control bindings on destination devices right in the rack. Simply toggle minimum value edit mode using a button configured on your MIDI hardware and all adjustments made will be recorded as the new minimum values for those adjusted controls. Likewise, you can activate the maximum value edit mode and update maximum value settings for those specific bindings. Editing both minimum and maximum settings preserves the bindings but establishes static values that are non-responsive.

It is important to note that only the controls that are manipulated will be re-programmed during editing of minimum and maximum values. All untouched bindings will preserve their defined ranges of response.

All of this is possible without a Combi and at a fraction of the impact on workload. RackNode cuts out the middle man and lets you get to work directly in the rack. The bindings can be used in combination with Combi instances, as well as CV and automation to achieve unseen levels of sound design and dynamic control during live performance.

I am incredibly excited about this one.
This will be the first video demo I make.
Now to resume the scheduled programming of my to-do list.

[Raveshaper]

Just a quick unofficial update, the progress on RackNode is going so well that it has merged with the MegaKnobs project.

The purpose of MegaKnobs was to allow a limited number of knobs to control a larger number of items. Just like Z-Triggers, each rotary would contain a stack of outputs, effectively turning 8 knobs into 128 (8 x 16).

If this specific surface type sounds useful on its own, I can still develop it. As it stands, it makes more sense to absorb it into RackNode to reduce some of the complexity.

The purpose of SuperKnobs is to make device controls responsive to specific ranges of value, making it possible for different actions to take place in Reason depending on the position of physical rotary controls. This surface is still planned, but has been pushed to the back for now. RackNode is going to be a very, very, unfathomably deep rabbit hole on its own, so I figure I've got time to get to smaller stuff some time later.

Sorry if that's disappointing, but this is actually good news. A leaner and more focused approach to this madness - which might not make it any easier to comprehend - is a better way to go.

Work is wrapping up on the initial beta of RackNode now, and then I will be completely focused on the cue point system. Great things are coming very soon.

[Raveshaper]

Another smaller update, progress has been a little slow.

Unfortunately, memory recall for RackNode has been scrapped. There is a way to do it that does work, but unfortunately there is no way to use it in surface files that have been precompiled to byte code. Also, RackNode is designed to run from one common source file ala Mackie, so the method of memory recall would actually fail if it was implemented (all nodes would parse and be preprogrammed the same way.) Which brings me to a fun fact.

There are roughly 1,168 surfaces in the RackNode system. This is way beyond the total number you could ever actually use at once. There are 16 units with 128 discreet I/O channels, 128 units with 8 channels multiplexed in 1:8 format, and 1,024 units with 1 input multiplexed in 1:128 format. There is also the option to define your own custom surface types, but that will just be confusing if I get into that now.

I have debugged the parsing engine for the 8 x 8 unit type, but I will grind through the other variants to make sure nothing weird gets through.

The only things left to do, besides checking the parsing, are adding variable speed rotary response for relative mode input and generating all of the remote map files (which unfortunately require me to create them manually). Oh, and a thorough write up of instructions and such.

Once that is completed, Z-Triggers, RackNode, and SystemClock should be ready for early testing. Which basically means really, really soon. Probably a matter of hours from this posting.

I'm only approaching a few people for testing at this stage, so don't be offended if I don't PM you. I know I'm going to be answering a lot of questions and I don't want to be swamped.

See you soon.

[Raveshaper]

Progress Report: 07/10/2015

1. RackNode has been completed.
The parsing engine was debugged and MIDI assignments exhibit stable behavior.

Memory recall using text files was scrapped due to incompatibility with compiling to byte code.

2. Z-Triggers has been completed.
The script has been renamed to DrumSystem.
This decision was driven by wanting a more descriptive name and to make it easier to access in the surface drop list.

An enormous thank you goes out to Kenni for graciously and generously donating his valuable time to batch process the remote map files required to run the RackNode system.

I am now devoting my attention to writing the user manual for the beta test, which should be done within a week.
This is by no means the end of the journey. Cue points, advanced resampling, and plugin mode support for multiple documents lie ahead.
But to be honest, this is exactly the break in the action I need. It's been a challenging build.

Again, initial release will be very limited. I know I'll be answering a lot of questions as it is.
Hopefully, I will be able to expand the testing phase once initial feedback rolls in and I learn how to clear up any confusion experienced by the users.
Stay tuned! This chapter of the book is finally written.

3. Fun Facts:

• There are 1,536 lines of code in the current stable build of RackNode.
• There are 1,168 surface script permutations contained within the RackNode system.
• RackNode was designed for up to two controllers.
• Development of RackNode has spanned more than a year from concept to completion.

[Raveshaper]

Tiny update: icons for the surfaces are done and the user's manual for the beta is wrapping up nicely.

It's all down to how well I can explain myself in writing at this point.