Skaldir
formerly known as Unicorn
I found the EX 1.63 installer for Win and Mac and the EX 1.64 installer for Win
Write me a PM if you need it.
Write me a PM if you need it.
Slate Trigger MIDI mistriggering problem
- Thread starter Ermz
- Start date
Ok here I am. I was just now made aware of this thread. First of all, guns down. Thanks.
In your ACCOUNT, there should be Trigger 1.64 and 1.65. From what I know:
1.65 MIDI CAPTURE is much more solid than simply inputting MIDI into the plugin. Is this how you are doing this Ermz? By doing MIDI capture in 1.65?
1.65 doesn't validate in Logic, so Logic guys need to use 1.64.
Ermz, have you tried the 1.65 Midi Capture?
Regarding support, we got back logged by over 4 days after our server crashed during the cyber monday sale. We're just now catching up. If you have a ticket that is going unanswered, email me the ticket number to slate@stevenslate.com
I've used the MIDI capture in Trigger and after I adjust the input settings, I've never had a problem using Nuendo 5.5.1. If there is a specific bug on a specific system, I want to find out the details and fix it.
How many years do I have to hang out here before you guys realize I'm not here to fuck anyone over, I want to make good quality stuff, I want to offer support, and all because I want you guys to make great music.
Steven
In your ACCOUNT, there should be Trigger 1.64 and 1.65. From what I know:
1.65 MIDI CAPTURE is much more solid than simply inputting MIDI into the plugin. Is this how you are doing this Ermz? By doing MIDI capture in 1.65?
1.65 doesn't validate in Logic, so Logic guys need to use 1.64.
Ermz, have you tried the 1.65 Midi Capture?
Regarding support, we got back logged by over 4 days after our server crashed during the cyber monday sale. We're just now catching up. If you have a ticket that is going unanswered, email me the ticket number to slate@stevenslate.com
I've used the MIDI capture in Trigger and after I adjust the input settings, I've never had a problem using Nuendo 5.5.1. If there is a specific bug on a specific system, I want to find out the details and fix it.
How many years do I have to hang out here before you guys realize I'm not here to fuck anyone over, I want to make good quality stuff, I want to offer support, and all because I want you guys to make great music.
Steven
Donovan S.
Member
The MIDI isn't the problem, at least for me. It's the MIDI IN of Trigger that is the problem. The output of Trigger when using MIDI In isn't always phase accurate. For me, about 5 samples out of 20 will be completely out of phase, triggering from MIDI that is spot on with the original drum tracks. The output of Trigger when using MIDI IN is out of time with the MIDI that it's using to trigger.
We created the MIDI Capture feature of TRIGGER 1.65 to address this issue. Using Midi Capture, you can capture audio, and drag the midi from the plugin interface to the Midi Track, and I've found this to be extremely accurate.
Donovan, have you tried this feature in 1.65? Ermz, is this the feature you are having problems with?
Steven
Donovan, have you tried this feature in 1.65? Ermz, is this the feature you are having problems with?
Steven
Donovan S.
Member
Using Midi created from Trigger, or MIDI created from Reapers MIDI capabilities, or even using Toontrack's Superior Drummer, I get the same problem. The MIDI capture is not the problem. Like I said, the output of Trigger is out of time with the MIDI it's using to trigger.
Right, so you are using the "old" midi way in realtime. This is not accurate due to limitations of MIDI. Therefore, our programmers developed a better system to create MIDI from Audio, using the capture and drag n drop feature, which is VERY accurate.
Let me know if I'm not following you correctly.
Steven
Let me know if I'm not following you correctly.
Steven
Donovan S.
Member
You aren't at all. Look at Ermz screenshot in the original post. MIDI is perfectly in time with the original snare hits, but Trigger is triggering it out of time. I've used the capture and drag & drop and gotten the same issue.
Got it.. so you want to trigger Slate Samples from a MIDI track.. not create a MIDI track from audio. Ok, let me check and see what's up after I do some testing.
Cheers,
Steven
Cheers,
Steven
Sloan
Sounds like shit!
Thank you slate!
I feel bad about all the shit this guy gets when he doesn't post in threads about his product on a forum that is not for his product's tech support. The fact that he even took the time to create an account to get/give feedback to customers says a lot to me, I'm not sure it's our place to get butt hurt when he doesn't immediately answer every request.
I feel bad about all the shit this guy gets when he doesn't post in threads about his product on a forum that is not for his product's tech support. The fact that he even took the time to create an account to get/give feedback to customers says a lot to me, I'm not sure it's our place to get butt hurt when he doesn't immediately answer every request.
Donovan S.
Member
I received an answer from tech support finally. To be honest, I am kinda shocked by the response.
"The "Phase accurate, multi-layered" refers to the phase accuracy within the plugin and for incoming audio. Trigger is not a midi drum sampler, it has these features for midi output, but it shines as a audio sample replacer. There are two things you can try to remedy this issue. One, is to use the live triggering setting for the plugin as to get the latency down. Another is to change the way you use Trigger, with incoming audio running on a aux track. That way the you have control over the samples an have less printing and editing. Sorry for the tardy response"
So basically I think he's telling me not to use the MIDI in function?
"The "Phase accurate, multi-layered" refers to the phase accuracy within the plugin and for incoming audio. Trigger is not a midi drum sampler, it has these features for midi output, but it shines as a audio sample replacer. There are two things you can try to remedy this issue. One, is to use the live triggering setting for the plugin as to get the latency down. Another is to change the way you use Trigger, with incoming audio running on a aux track. That way the you have control over the samples an have less printing and editing. Sorry for the tardy response"
So basically I think he's telling me not to use the MIDI in function?
I have a meeting with the program team regarding the MIDI IN. But please know, that TRIGGER's main function is that of an audio triggering plugin (which imo it does better than anything on the market) and producing MIDI from audio (again, I've found this to be the best). Triggering audio samples with MIDI is better meant for a virtual instrument, like the upcoming SSD4.
However, this MIDI in Function in Trigger can and will be improved in a future version.
Cheers,
Steven
However, this MIDI in Function in Trigger can and will be improved in a future version.
Cheers,
Steven
greyskull
Member
- Mar 22, 2006
- 6,072
- 7
- 38
Bizarre as it may be... this is how i use it most as I like the control midi let's you have over every hit!
Donovan S.
Member
Triggering via MIDI is so much easier though, at least for me. You have direct control of every hit and can control the velocity directly rather than relying on any software's algorithms to decide the velocities for you. I formerly wrestled with Trigger never giving hard hits when I wanted them, and then not giving me soft hits when I wanted them after I changed the settings to give me hard hits. Sure, I could use 2 instances of Trigger, use leakage suppression, automation, adjust the settings more, etc. etc. but that takes a lot longer than just triggering via MIDI and avoiding all of that to begin with.
Loading an entire virtual instrument would be a big hassle for the simple act of triggering my own samples, and that's if I could even use my own samples in SSD4.
I just tried the Drumagog 5 demo and it worked flawlessly triggering via MIDI, just sayin'.
Loading an entire virtual instrument would be a big hassle for the simple act of triggering my own samples, and that's if I could even use my own samples in SSD4.
I just tried the Drumagog 5 demo and it worked flawlessly triggering via MIDI, just sayin'.
AdamWathan
Member
When triggering Trigger via MIDI, it does not wait for it's reported latency time to send the audio back to the host, that is the problem.
If Trigger has a latency of 485 samples and you feed it MIDI, it plays the sample INSTANTLY, and then the host sees that Trigger is reporting 485 samples latency, so the sample now ends up 485 samples early. It is always consistently out by the exact amount of latency the plugin is reporting. This is not a problem with audio because Trigger uses that 485 samples to analyze the incoming transient, then play the sample, and when the host compensates for that 485 samples it is now in time. But since Trigger does not need to analyze MIDI for transients, it fires the sample right away and the sample ends up being early after the host compensates for the latency Trigger is reporting.
The fix is just to force Trigger to wait 485 samples before playing back the sample after receiving the MIDI data.
I solve this by simply adding a time adjustment plugin immediately after Trigger and setting it to the number of samples Trigger is reporting as it's latency (when only using MIDI to feed Trigger of course). This results in perfect output every time for me, but it is a silly work around and should not be necessary.
If Trigger has a latency of 485 samples and you feed it MIDI, it plays the sample INSTANTLY, and then the host sees that Trigger is reporting 485 samples latency, so the sample now ends up 485 samples early. It is always consistently out by the exact amount of latency the plugin is reporting. This is not a problem with audio because Trigger uses that 485 samples to analyze the incoming transient, then play the sample, and when the host compensates for that 485 samples it is now in time. But since Trigger does not need to analyze MIDI for transients, it fires the sample right away and the sample ends up being early after the host compensates for the latency Trigger is reporting.
The fix is just to force Trigger to wait 485 samples before playing back the sample after receiving the MIDI data.
I solve this by simply adding a time adjustment plugin immediately after Trigger and setting it to the number of samples Trigger is reporting as it's latency (when only using MIDI to feed Trigger of course). This results in perfect output every time for me, but it is a silly work around and should not be necessary.
Donovan S.
Member
This is a problem, but not the problem Ermz is referring to in the original post. Look at the screenshot he posted. First hit is triggered fine from the source MIDI, the next hit is totally out of time with the source MIDI. It wouldn't be nearly as much trouble if everything was out of time by a fixed amount.
Sure would be nice if Trigger was more accurate in this regard, but I've had this problem with apTrigga also.
Live mode might work better, but what I've done is trigger off something like the sample player in REAPER for Trigger to trigger off on (weird sentence).
Live mode might work better, but what I've done is trigger off something like the sample player in REAPER for Trigger to trigger off on (weird sentence).
AdamWathan
Member
Spoke to the programming team. Now that we realize that many people want to trigger FROM MIDI, there is a definite fix for the midi input engine that would make it spot on, look for it in an update.
Cheers,
Steven
Cheers,
Steven
Thank you, that is all we wanted.
I completely understand that the development team may have envisioned the primary use of Trigger to be Audio > Sample, or Audio > MIDI, but if 'MIDI in' functionality was never truly refined, then why was it added into the plug-in in the first place? If I had known this from the start, it would have been a non-issue, as I'd have used Drumagog to key all the samples. My confusion just came from using a feature that was obviously implemented, but fundamentally broken - without documentation.
What Adam mentioned was an interesting phenomena too. He articulated it much better than I ever could, but I also found in the past that there were disparities with the way trigger reported latency and triggered samples, so they were always off by a fixed amount of time. To my knowledge, you guys fixed with with the new MIDI capture features of 1.65 - the issue I reported notwithstanding, of course.
Thanks again. Eagerly awaiting the update!
I completely understand that the development team may have envisioned the primary use of Trigger to be Audio > Sample, or Audio > MIDI, but if 'MIDI in' functionality was never truly refined, then why was it added into the plug-in in the first place? If I had known this from the start, it would have been a non-issue, as I'd have used Drumagog to key all the samples. My confusion just came from using a feature that was obviously implemented, but fundamentally broken - without documentation.
What Adam mentioned was an interesting phenomena too. He articulated it much better than I ever could, but I also found in the past that there were disparities with the way trigger reported latency and triggered samples, so they were always off by a fixed amount of time. To my knowledge, you guys fixed with with the new MIDI capture features of 1.65 - the issue I reported notwithstanding, of course.
Thanks again. Eagerly awaiting the update!
