MDrummer. How does midi command works? I'm very confused :(

[AMD]

Hi, all.
How can I asign midi notes to a specific loops from the Loop Box?

Here is what I've been trying:

In MDrumer VSt --- Loop Box Sellector;

I loaded two keys with different loops.

In FLs --- Piano Roll;

I inserted a note in key C4, bar 1.

Now, when I press FLs play button, Mdrummer does not asign this note to a specific loop; It plays both loops respectively as FLs repeats the loop; which means MDrummer doesn't restrict any midi note to any loop from the Loop Sellector, it even produces no sound while the same note is playing untill it repeats again. Hope that makes sense.


Now about the Mdrummer options:

I have the (Random loop) option disabled in MDrummer as well as (Auto Breaks).

Maybe I'm not understanding the whole point of the midi command feature and that MDrummer doesn't work this way.

I watched every Vedio on the site, but that doesn't help me to understand this problem.

Thanks for anyone to help with this. MDrummer is GREAT and I don't want to miss it.

[MeldaProduction]

Well, I don't really understand what you are trying to do. First, C4 seems like "stop" command assuming the lowest octave is -2. I believe C-1 is beat, so assuming there is a loop in loopbox C in beat section, when you press C-1, this loop should start. If there are more of them, MDrummer chooses randomly/by index. If you have another loop in say G, then when you press G-1, MDrummer should play that one. And if you press F-1 in this scenario, MDrummer finds the nearest one, which is G and plays it.

[AMD]

Well, I don't really understand what you are trying to do. First, C4 seems like "stop" command assuming the lowest octave is -2. I believe C-1 is beat, so assuming there is a loop in loopbox C in beat section, when you press C-1, this loop should start. If there are more of them, MDrummer chooses randomly/by index. If you have another loop in say G, then when you press G-1, MDrummer should play that one. And if you press F-1 in this scenario, MDrummer finds the nearest one, which is G and plays it..

According to you reply it seems that I wasn't doing anything wrong. The following confirms my understanding to your instructions:

In the Loopbox I loaded C with one loop, G with another.

Now, when I hit play in fLs Both notes C-1 and G-1 plays the same loop from the loopbox which is loop G.

Could it be because I'm working on the Demo version, Or maybe I am missing something in the options?

Again, Your help highly appreciated.

[MeldaProduction]

Well, that's weird. I think you must be doing something wrong, but I don't have any idea what. Please send me a FL Studio project to info@meldaproduction.com and I'll check it.

[AMD]

Well, that's weird. I think you must be doing something wrong, but I don't have any idea what. Please send me a FL Studio project to info@meldaproduction.com and I'll check it.

Thanks for this help. I just sent an email with two project files : FLs and Reaper.

Hope you could discover the problem.

This should be my last stage in assissig MDrummer as a preparation to buying it very soon.

[MeldaProduction]

Well, these are the results:

1) With Reaper you were a victim of the mess in octave numbering. Reaper indexes octaves from -1 for whatever reason. FL Studio from 0. Both of them are wrong I believe. Octaves should be counted from -2, at least most of the hosts such as Cubase or Live do that.

So just try to put all notes an octave down, to their C0, which is C-1 in reality. The way it is not you are triggering breaks every bar. That's pretty unusual, though it works if you disable "random loops". But still, it shouldn't be used like this, because breaks are just breaks .

2) With FL Studio - well, I'm afraid it's buggy FL Studio... FL Studio reports invalid position AND/OR sends the events too late. This makes MDrummer think the note (command) actually belongs to the next bar. Just try using 4 bars instead of just 2, MDrummer will be 1 bar behind when listening to commands. Fortunately there's a simple hack - move all notes a little to the left, thus "compensating for the FL Studio bug-latency" .

Hope this helps.

[tony tony chopper]

Both of them are wrong I believe.

All 3 are correct. -2 is Steinberg, 0 is Cakewalk, -1 sometimes used as well. In the VST world it's usually -2 because owned by Steinberg, but that doesn't mean it's a better standard.

2) With FL Studio - well, I'm afraid it's buggy FL Studio... FL Studio reports invalid position AND/OR sends the events too late.

I've asked Fred to check this as I have no idea what it's about

[reflex]

2) With FL Studio - well, I'm afraid it's buggy FL Studio... FL Studio reports invalid position AND/OR sends the events too late. This makes MDrummer think the note (command) actually belongs to the next bar. Just try using 4 bars instead of just 2, MDrummer will be 1 bar behind when listening to commands. Fortunately there's a simple hack - move all notes a little to the left, thus "compensating for the FL Studio bug-latency" .

FL always reports position zero for events, as they're always sent at the start of a buffer. This is because FL mixes in ticks and events are aligned to ticks.

Could you elaborate on the way in which FL's events are too late?

You can always pm me, btw.

[pheeleep]

Ah, Reflex to the rescue! Thanks for your willingness to work this out reflex. And thank you gol putting the wheels in motion.

[MeldaProduction]

2) With FL Studio - well, I'm afraid it's buggy FL Studio... FL Studio reports invalid position AND/OR sends the events too late. This makes MDrummer think the note (command) actually belongs to the next bar. Just try using 4 bars instead of just 2, MDrummer will be 1 bar behind when listening to commands. Fortunately there's a simple hack - move all notes a little to the left, thus "compensating for the FL Studio bug-latency" .

FL always reports position zero for events, as they're always sent at the start of a buffer. This is because FL mixes in ticks and events are aligned to ticks.

Could you elaborate on the way in which FL's events are too late?

You can always pm me, btw.

I'm afraid it is impossible to "adjust" to the invalid values. MDrummer already has to work with different imperfections with different hosts (and there's many of them ) and this just cannot be done.

Anyway I don't understand the reason for that. You should send nonzero event offset in the previous buffer and since you always know events coming up, you should be able to do that. I'm not saying it's easy, but every other hosts managed to do that. Right now positions of almost all events are simply invalid.

[reflex]

Anyway I don't understand the reason for that. You should send nonzero event offset in the previous buffer and since you always know events coming up, you should be able to do that. I'm not saying it's easy, but every other hosts managed to do that. Right now positions of almost all events are simply invalid.

FL triggers events inbetween processing buffers. In VST speak, events are always supposed to be triggered at the start of processing, which means a zero offset.

This works fairly well because FL's buffers are normally very small (the ticks I mentioned earlier).

I'm not asking you to adjust your plugin, but I'd like to understand why the timing of the events is invalid in this case.

[MeldaProduction]

MDrummer needs to know the command (note) ideally before it actually happens. In all other hosts, command "start beat with level 100%" happens exactly at first quarter and since it is reported before it happens (before the buffer), MDrummer knows "next bar will be beat with level 100%". In your case MDrummer already IS in the next bar and since it cannot change levels between bars, it must consider it "command for the next bar" - error.

Another scenario - you put "play break" at 3rd quarter. MDrummer receives the command, finds available break (or fill if you wish) and schedules switch to it. The break may start at 4th quarter, then everything is fine. But if it starts at 3rd quarter, it may contain a hit (note) played exactly at 3rd quarter, which won't be played, because that time MDrummer wasn't playing that break and it started to play it after the 3rd quarter (which may be fine, but it must start playing AT the moment of the command) - error.

The engine is extremely complicated, but these are pretty simple scenarios, which proof MDrummer needs events in time. Basically if you think about it, EVERY instrument is not working correctly in FL Studio, because all of them are playing behind. It often may not matter, because people tend to play ahead , but imagine even a simple loop player, which would just trigger "bar-long" loops. In these conditions it would either be out-of-sync or cause zipper-noise due to switching between loops after one already started.

Hope this helps.

[MeldaProduction]

Btw. I just checked size of blocks created by FL Studio. It seems limited by 256 or something. With my ASIO set to 256 samples it was doing things like 200, 56, 150, 96 ... Obviously to sum to the device block sizes with limit about 200.

First this is not a good idea. Usually people call this "torture test", so I wouldn't be surprised if that wouldn't work for some plugins. MeldaProduction should be fine though

But second - you really consider this "very small" blocks? For MIDI timing? I mean are you kidding? I cannot even play on electric drums with latency larger than 256! When recording MIDI of any instrument, including piano which has pretty long attack, 256 samples is maximum for me. And I know folks making hip-hop grooves, who literally move notes by less than milliseconds in the editor. Even I don't hear the difference, but they can .

Timing is important! It may not be so important in techno for example (as I understand FL Studio is for dance music?), but still...

[reflex]

I'm afraid I don't agree with you that this is a bug in FL.

I understand now why you need the notes to be early, but what you're doing doesn't really have any guarantees in VST. In other hosts it's also possible to get note events with an offset of zero, but it won't happen every time like in FL. So while your plugin will work correctly in most cases, there will be some glitches (i.e. one extra bar of latency in processing the event) from time to time.

Let's imagine there are events with an offset of 1, triggered 1 sample after the start of a bar. This event will then only have an effect when the next bar starts, so the latency for that event will be 1 complete bar minus one sample.

So why is an offset of 0 samples invalid, but not one of 1, 2 or ...?

What I'm trying to say is that you can't assume anything about the offset of events that you receive. They can be any value up to the size of the processing buffer minus 1.

[MeldaProduction]

I'm afraid I don't agree with you that this is a bug in FL.

I'm afraid it is. Since FL Studio doesn't report timing correctly, each event will always be late of up to 200 samples in my case! I believe this is not acceptable even in normal VSTis (for me it is, though I would like not to know about that , but for some people definitely not).

I understand now why you need the notes to be early, but what you're doing doesn't really have any guarantees in VST. In other hosts it's also possible to get note events with an offset of zero, but it won't happen every time like in FL. So while your plugin will work correctly in most cases, there will be some glitches (i.e. one extra bar of latency in processing the event) from time to time.

Let's imagine there are events with an offset of 1, triggered 1 sample after the start of a bar. This event will then only have an effect when the next bar starts, so the latency for that event will be 1 complete bar minus one sample.

So why is an offset of 0 samples invalid, but not one of 1, 2 or ...?

What I'm trying to say is that you can't assume anything about the offset of events that you receive. They can be any value up to the size of the processing buffer minus 1.

I don't follow. Hosts provide offsets of each note and general timing stuff like PPQ position (position in quarters from the beginning). With that information plugin can determine almost accurate position of each event as PPQ. Some imperfection is probable, so there is some rounding, but events ALWAYS have to be reported before they happen. In FL Studio they do NOT.