Notifications
Clear all

Starting a Drum Groove - Which Trigger Start/Stop to Use


Matthew Doudt
(@matthew-doudt)
New Member
Joined: 6 days ago
Posts: 3
Topic starter  

Hey Everyone!

I'm using Unify with a slew of plugins along with a studio of both Analog & Digital gear and attempting to time lock everything during live performance/recordings etc.  I'm controlling Unify from both a Yamaha Digital Piano and an Arturia Keystep Pro.  I can get multi-channeled midi into Unify just fine and everything that's just a sound source works perfectly.  What I'm struggling with is getting a drum program (specifically MicroTonic) to start and stop exactly with a keypress which is much more accurate than clicking the transport controls.

I've tried all the different trigger options and even with Microtonic only receiving on Channel 1, the drums will either go ahead and start from any midi channel or not start/stop consistently.  Its rather bizarre.  I want to be able to start and stop Microtonic and also change its patterns which you can do with keyboard notes but I don't understand how Unify's Transport Control connects to a VST that has a Start Stop button.

Any help?

The other weird thing is that I can't communicate with Microtonic once the sequencer has started on my Keystep Pro.  If the sequencer/clock isn't running I can start and stop Microtonic with a latched note just fine but I can't add that same note into the Keystep's sequencer or play/latch that note live once the keystep sequencer is running.

If I want the keystep sequencer running prior to Microtonic playing, I have to start Microtonic with a keypress but with the first unify knob turned down so that the drum's Sequencer is off.  Then I start my keystep's sequencer then turn the knob to bring in Microtonic.

My guess is that what's going on is an external sequencer (Keystep) controlling Unify with an embedded sequencer (Microtonic) and the Unify Transport control doesn't have the exact setting I need to connect all of these and give me the control of each independently (from a keyboard)??  

I'm still figuring it out and I have work arounds but they're a lot of steps to remember when playing live. 

I looked in the Unify Owner's Manual for a detailed description of the Transport Control Options and didn't find it... Or Latching on each layer.  But its possible I just didn't find the right section.

Thanks in advance for any help!

Matt

This topic was modified 6 days ago by Matthew Doudt

Quote
getdunne
(@getdunne)
Member Admin
Joined: 2 years ago
Posts: 2788
 

@matthew-doudt

I think this is the start of a longer conversation. You raise a number of issues, which are complex enough that we may need to look at them one at a time, ideally in the context of one test patch at a time. You can share patches here as file attachments; I advise as follows:

  1. Create all test patches in the Unify "User Library", so others trying them will know where they go.
  2. Attach only .zip files, because the Forum software accepts only a few file types.
  3. If your patch requires other supporting files, e.g. MIDI files, consider creating a .guru file (see below)

Concerning the Unify Transport:

  • The main page describing the Transport in the Unify manual is https://pluginguru.net/unify/manual/doku.php?id=transport (or just enter "transport" in the search box)
  • The Transport does have controls to limit the trigger note-range, but there is currently no way to filter based on MIDI channel. You may be able to achieve this by using embedded Unify instances, and using MIDI channel filtering on each INST layer containing an embedded instance. We can discuss further if you wish.
  • Speaking more generally, the whole reason Unify even has its own transport (aka playhead), is because this is the only way to synchronize multiple independent plug-ins; DAWs have a transport for the same reason. We don't claim that Unify's transport implementation is perfect; in fact, it's been an area of ongoing development for a long time. I'm very interested in understanding what you're trying to achieve, as it may point toward future improvements. Achieving all your goals may take quite some time.

About .guru files:

I recently added a new Appendix to the Unify manual describing .guru files in some detail: https://pluginguru.net/unify/manual/doku.php?id=guru-files. Basically, a .guru file is a .zip archive, with the .zip extension changed to .guru, whose contents are structured so they unzip perfectly within the main Unify data folder. The manual page explains how to do this.

If you want to make and share a test patch using, say, a specific MIDI file:

  • Put the .mid file into the MIDI Files sub-folder of the User Library folder, and reference it there in MIDIBox.
  • Save your patch into the User Library, so the resulting .unify file goes into the Patches sub-folder of the User Library folder.
  • Create a new empty folder (somewhere on your computer, preferably NOT under the main Unify data folder) called Libraries, create an empty sub-folder called User Library inside that, and empty Patches and MIDI Files sub-folders below it.
  • Copy your patch(es) into the new empty Patches folder, and your .mid file(s) into the MIDI Files folder.
  • Navigate back upward, and zip (compress) your entire new Libraries folder.
  • Check the structure of your .zip archive as follows: 
    • If you open this new .zip file (easiest on Windows), you should see the Libraries folder inside it, and nothing else at the top level.
    • (If you're on a Mac, you may not have a way to "open" the .zip file without actually uncompressing it. If you want to check that you got the structure right, put the .zip file somewhere else and unzip it there, so MacOS doesn't try to overwrite the Libraries folder you originally compressed.)
  • If you want, you can now rename your .zip file, changing the extension from .zip to .guru. Dragging this into Unify will quickly "install" your patch and supporting file(s) so everything lands in the right place.
  • However, if your goal is to share your test patch and supporting file(s) here on the Forum (or even on some other online service), it's better to leave the extension as .zip, and then just explain in your post that it should be renamed from .zip to .guru after downloading.

ReplyQuote
Matthew Doudt
(@matthew-doudt)
New Member
Joined: 6 days ago
Posts: 3
Topic starter  

@getdunne - Thank you so much for this start and open door for additional communication!  I'll work on putting together some things for you and get back next week!  I seriously appreciate you guys and all you do.  Unify is Glorious!  Y'all are Brilliant and only excitement as I dig deeper into its workings and you guys continue to build into it!

Much Thanks!

Matt


getdunne liked
ReplyQuote
getdunne
(@getdunne)
Member Admin
Joined: 2 years ago
Posts: 2788
 

@matthew-doudt

If you just want to get started, don't bother about figuring out how to make a complete .guru file. Those are great for sharing your work with others later, but for now you can just zip whichever files you need, and write something in your post about how they're related. I'll figure it out.


ReplyQuote
Share: