Midi Commands delay

I need control over the order of MIDI commands.

So: First load, then sync.

Useful with macro's that don't work otherwise..

I've been doing a lot of workarounds that don't work to well
because of the order of execution.

Come to think of it.. a pause option would be nice too!

So a complete solution can be archived by adding one field: execution delay.
A user can type in the amount of delay in milliseconds and control order and/ or pause...

Imagine these macros: But I can think of many, many more...

1 Workaround for Deck slave

Load Deck
(Pause 50 ms)
Sync

2 Load track and Cue to first marker
(yeah I know loadmarkers. this is faster for me)

Load Deck
(Pause 50 ms)
Sync
Jump to next Marker

The potential of this system.. pfft.

Anyone with me on this?

Karlos, I'm counting on you!
Signaturex.. I'm sure you agree..
BDX?

Lets get this thing off the ground.

 

Nobody?

Try loading a track and sync to master at the same time..

Not possible., you need to load first, then press sync,
but you cannot do it with 1 button..

With Midi command delay you can!

Or:

Get fx 1 to change to delay,
then change value to 1/8
and then move Dry/Wet down

With just one button.. yeah..

I hoped on some more support on this one,
but maybe nobody needs scripting..

 

Or, since we all need the current playlist workaround:

(first set History to fav x)

Then one command:

Select fav x
(Delay 5 ms) Jump to end of list
Add to Fav Y (Current playlist)

 

Yes I can see how it would be useful.

Rather than introducing full scripting, you could set a parameter for the functions (say 'Order' from 0-9)

Default setting would be zero. Execution of functions with the same 'Order' setting would be as present (meaning the change would be not effect current .tsi files and would be transparent for those not needing it).

Functions allocated a higher 'Order' setting would be executed afterwards. So by changing the 'Order' setting you can alter the order in which functions are executed.

 

indeed.. only with order, there is no wa of determining if the previous command is finished..
(some commands take some time to excecute: load a deck)
so with a delay you can set order & pause..

0 ms: 1st command
1 ms: 2nd command
30 ms: 3rd command and 28 ms pause

Etc

You could with this sytem control with one button: (just an extreme example)

Select a track form bottom of Fav A
Load in Deck B
Add to Fav B
Jump to next Cuemarker
Loop 8 bars
and Play

Or set temporary commands (switch back after x ms)
Glad you see the potential.

All what is needed is one extra field in the Midi Command Page

 

Yes, your way is better (forgot that loading tracks etc could take a while).

 

This sure sounds like a great idea... does PhiL or some other native representative, got anything to comment about this?

Is this a realistic request, could it be done? How much time would it take to develop?

 

If this would be implemented it would open up a world of possibilities for all power-users..

Many custom workarounds would finally work or work better..
Different buttons could be combined..

Load - Sync - Select - Change FX .... you name it..

Different FX settings when loading loops: Possible
Make your own advanced FX presets: Possible
Making your own playlists on the fly: Possible

Because you can chain events and commands...
Its like scripting on a Mac (Automator)

IMHO this is not that difficult to implement..
I suspect delay is already in the program, only not editable for end users..

BUT, people that don't understand the feature: (execution delay vs audio delay )
could seriously mess up their setup..

So before NI would implement it, more support is needed for this request..

I hope more people will see the value of this feature..

 

Yeah Marc this would also resolve (maybe) the problem we have discussed before about assigning 2 Browser commands to one hot key which at present is not possible.

Load Stopped Deck > Fav Add > Fav Select.

(ps marc sorry about the late reply ive got a terrible cold been in bed for 2 days eeeuch)

 

Hee Karlos,

I knew I could count on you..
Yeah, this will fix that, and a lot more..

Get well soon!

 

Hmmm.

Couldn't this be achieved with a program like autohotkey (or Mac equivalent)? You could set up macros with that. You could possibly also do stuff like:

On command (say windows+h)
Cursor moves to the hotcue drop down box and clicks, you get to have a look at what your hotcues are named without jumping to them or using the mouse. On release, the cursor moves back to its original position.

 

Since I'm yet to dive into MIDI mappings, I'm just guessing here, but are you saying that the functions are asynchronous? Meaning that they don't wait for the previous function to return before issuing the next command in the queue?

Because if they were synchronous, we wouldn't need any kind of delay; we would just set the order in which we want the different command to be executed and they'd work just like that...

But as said, I haven't yet done any MIDI-mapping, that's still ahead of me later this week when I have time to pick up the new controller.

 

Yes, there all all sorts of programs you could try to do this with.

Quickeys and Quicksilver, maybe even Automator,

But I don't know how to trigger that from my 4D...
---

As far as I can tell, all commands in a Macro are performed at the same time.

Some things need an order:

Load a certain FX, THEN move wet Dry
Load to Deck A, then press SYNC.

Check MIDI mappings.. Its a great tool to personalize your setup.

 

This is a stab in the dark so you real midi-heads tell me this is stupid idf it is but: Maybe a Priority Field in the Assignment Table.
If HotKey 'A' has 3 different Controls assigned to it in the Priority Field you would place '1' or '2' or '3' in the field for each command so that the 3 commands loaded in that order.

All commands would have the default '1' in the Priority Field unless changed by the user.

Silly or do-able?
Thoughts?

 

Hi Karlos,

For order, the program would need feedback to see if the command is executed.
With a delay, this is not needed..

Plus, it's much easier to implement for NI, and more flexible to control..

Example

0 ms: 1st command
1 ms: 2nd command
30 ms: 3rd command and 28 ms pause

 

And with a delay, guess what happens if the action you requested doesn't execute as fast as you've set the delay for... on my opinion as a software engineer, both implementations have their problems. If I were to design this, I'd simply create a simple way of ordering the commands, and make them all synchronous (ie. the next one will not fire before the previous has finished). But once again, that's just me...

 

That would be my preference too..

no fiddling with delay times.. indeed.

 

Thats kinda what i meant . One after the other in order.
But i see the flaw as well.

What about a way of 'Binding' commands so that the program doesnt have to feedback. 3 commands linked.

I dunno, im totally guessing here but its worth looking stupid for a while just in case you strike gold once in a while

 

Then the macro won't work... which gives the same result as the current situation...

The request for a delay was made with one thing in mind:

To get control over order of events triggered by MIDI commands..

But, I suspect it will require serious programming to make all functions
communicate their status: activated/ switched/ loaded or whatever.

Since only power-users that program their only MIDI and Macro's will use it
(look at the heavy support this feature request is getting: 4x out of 100+ viewings)
I seriously doubt that NI will invest that much time in a function like this.

So, that's why I made a request for a delay..

It enables a few users to make their macro's work.

To make virtual shortcuts that are not their yet..
And I suspect its already in the program, only not editable.. yet.

People who need this can work with this trial and error programming.

 

Marc this is a great idea, but I must say I don't think it's as easy to implement as you may think.

For your scheme NI would need to develop:

a.) A way for the assignment editor to know which commands are associated with a certain macro (are they always the ones associated with the same MIDI CC#?)

b.) Develop a priority field to dictate the order of events.

c.) Make sure the events actually execute before the next one starts (maybe, as you say, a default 10 ms before and after the event would ensure this but it would depend on system performance). If you let the user set this parameter yet another field would have to be developed for the assignments.

Regardless whether your idea is good or not, I think inadvertently you have shed light on a greater issue - the MIDI assignment editor itself.

As it stands now, the MIDI editor is just a list of commands that respond to certain MIDI CC's. Given all the possibilities with modifiers and macros nowadays, the MIDI editor is dumb (in the programming sense). It needs to be made smart to keep up with the smart ways people are using MIDI with Traktor.

What do I mean by smart? By smart I mean using Object Oriented Programming principles. Let me explain.

First off, having everything in one ginormous list as it is now is unmanageable. There needs to be a Macro Editor where you make, edit, and name your own macros. You then assign that macro to a button in the main editor to use it. It is in this Macro Editor where you would have the priority and delay fields available to give Marc's functionality.

If you're gonna go the Object Oriented way, you should go all the way. There could also be a Modifier Editor where you have the list of your modifiers and the commands associated with them - expanded or hidden like a file tree. Here you could, say, assign a macro you made in the Macro Editor to a modified MIDI CC with one click! Everything remains nice and tidy and you only look at stuff you need to.

You can tell NI has noticed the problem with their current MIDI editor because with TPro they've added the comment field to help users decipher the madness. But this is unsatisfactory considering that using Traktor to its potential nowadays is not unlike sitting down and writing a computer program. Except with the current MIDI editor it's like trying to program an operating system in assembly language! You need programming tools!

I mean, I can't believe they haven't even added colour coding functionality into the MIDI editor yet. Different colours for assignments linked to modifiers, conflicting assignments, and macro assignments - set by the user - would make a world of a difference. And that's easy to implement. All we have now is yellow. Just yellow.

Phew. What a rant. To summarize - implementing Marc's priority macro should only be done if it's done properly, as in redesigning the entire MIDI Assignment Editor using an Object Oriented philosophy.

And that is why I think it would be difficult for NI to implement.