Why might the Note-in block seem to respond intermittently?

xeodon

I am using LoopMIDI in Win 10 to connect OpenMusic to a Reaktor Rack. I have a simple 4 note pattern in OM and they should play in a row but sometimes one or more do not play. Tested same setup reading MIDI with MIDI OX. All notes seems to be generating MIDI note on and note off via LoopMIDI. Also tested Loop MIDI into Bitwig studio and all notes play reliably. Note in block responds fine to a keyboard input.

I am baffled. Anyone else using this type of setup?

Thanks,

Don

xeodon

Further research most of today. It seems to be the MIDI out block. It skips outputting notes and not the same notes. I tried many combinations using various input controllers and hardware on outputs but everything works fine EXCEPT output from Open Music via LoopMIDI. I will continue to experiment and workaround the issue but any comments would be welcome.

Don

Paule

A similar issue was on MIDI In and colB wrote a new MIDI In Block.

Please ask hin.

xeodon

Hello and thanks,

Since I am new here how would I get in touch with colB?

Thanks,

Don

xeodon

Never mind previous post. I figured it out!

colB

So first of all, what is this for?

IMO there are very few midi processing situations where I would choose to use Blocks. It's a job for Primary and/or core processing.

Midi represents music as a stream of note on and note off events that contain pitch information. Blocks represent music as a (virtually) continuous signal (stream of audio events) representing pitch, and a similar continuous gate signal. Very different. So to convert between the two, you have to make assumptions and compromises. Converting twice, once from Midi to Blocks, then once from Blocks to Midi is just asking for trouble!

-------------------------------------

If there is a good reason for doing it this way, what I would first do is check that the conversion to blocks is good - so set up some block to play the converted midi signal, and maybe look at the gate signal on a scope Block. At least then you know for sure that the problem is on the output (or input).

generally these sorts of Midi problems relate to notes overlapping so some notes are dropped or hang, or alternatively to note events coming too fast. The Midi specification has a speed limit that a lot of implementers just ignore, so its possible that the output events could be just too fast for the target (unlikely these days, but you never know). It should be possible to use a midi monitor to check what the midi output looks like.

---------------------------

What's your cpu load looking like?

-----------------------------

The factory midi in Block was broken, hanging notes in some particular situations, I posted a Block that didn't have those problems, but I already had the code from an old project, it's really not something that you can just throw together in a spare hour, it's really quite involved to deal with all the potential corner cases.

I haven't looked at converting from Block to midi out, I just don't have a use for that. In most cases these problems are just operator error, so take some time to dig in further. It could be a bug, in the midi out Block, but that's less likely than a bug in you project.

Unfortunately I don't have loopMidi or open music, so can't help testing. Main thing is to break it down into stages and try to confirm each stage is doing what it should be with some sort of repeatable test.

So if its the input that's the problem, you should be able to isolate that within Block on a scope... and if its the output, you should be able to demonstrate it with just a rack and some midi output using a midi monitor of some kind. If you can't do either of those, then maybe the problem is Open Music?

colB

Please post a pic of your rack, and a pic of your open music pattern

Also set up a scope in your rack, wire the gate signal from the note in block, and post that

(to get the timescale right wire it first to the pitch then adjust the time setting so that it shows the change in pitch as steps, then swap that out for the gate signal)

colB

Hmm, looking at that midi out block, its down-sampled to the Primary control rate which is 400Hz by default. So if the gap between the end of one note and the beginning of the next is shorter than 2.5ms the next note will not register.

Options:

*Make sure to leave a small gap between notes - should be doing this anyway, otherwise converting MIDI to (virtual) CV will never work.

*increase the Reaktor control rate in settings - definitely try this, its so easy to do

*edit the Block to run at some faster rate - what I would do, but might not be necessary if you try the other two.

I'm quite surprised that a factory Block is lock synced to the Primary control rate - seems like a terrible design decision IMO. I do like the idea of limiting the rate of output MIDI event, but there are MUCH better ways to achieve that.

xeodon

Hello colB,

Thanks for your VERY detailed answer! A lot of good info in there. Basically I was just experimenting as part of my learning what I can and can't use Reaktor for. I did a lot of the troubleshooting as you suggested prior to posting. The end result is for some reason when I feed OM into my very simple rack (just note-in to MIDI out) and monitor the MIDI out with a MIDI monitor (MIDIOx) I see 2 note offs generated between each note on. I am guessing this is what is causing the next note in line to be missed. No other input to the rack generates that output. Your suggestion about Reaktor control rate is worth investigating as this definitely seems to be a timing issue though I'm not sure why it would generate two note offs. My test case was a simple four 1/4 note scale so it was easy to hear the missing notes. Note duration was 1000ms between onsets so the notes were not close. I even tried a load of fast notes from my keyboard and these were tracked fine at the MIDI out. Feeding this same simple scale into a simple internal Reaktor synth caused no issues and the MIDI sent by OM did not have the extra note offs when looked at in the MIDI monitor. I think this is just a quirky interaction between OM and Reaktor. The MIDI out does not seem to be broken in any other test I made. It is also possible that Open Music is doing something odd but I did not see it. Windows is not it's primary platform so who knows?

You asked about the application - I was thinking of feeding OM algorithmically generated MIDI into Reaktor to use internally in the rack as well as sending it out to my modular setup (thus the MIDI out) I have Mutable Instruments Yarns for MIDI as well as a couple of Expert Sleepers ES-8 modules. Using those modules with CV out from Reaktor worked great so I had both options.

Anyway thanks again for your answer. I'll post again if I find anything of value.

Don

colB

Duration between note start is irrelevant. Time between end of one note and start of next is important. It must be more than 2.5ms for Factory Blocks to work properly in this configuration using default control rate.

xeodon

Sorry if I misunderstood. So in other words there should be more than 2.5 ms between a note-off message and the next note-on ?? I've not had to dig into the nuts and bolts of MIDI before so I am not sure how I would even assure that gap exists between not events. I think increasing the control rate is an experiment worth trying. If for no other reason than just to understand this a bit better.

Thanks

Don

colB

https://community.native-instruments.com/discussion/comment/102459#Comment_102459

That's why I asked you to post a pic of your sequence. If the notes overlap, then it wont work.

Midi doesn't understand notes, only on and off events - that why they can get hung or dropped, because a note needs two events, but if you lose one for some reason, everything is... suboptimal :)

To convert a midi sequence to monophonic signals, you need the pitch and the gate... but if the end of one note overlaps the start of the next, the gate stays open - its just on/open through that transition. That's fine in Blocks, but if you then try to convert back to Midi, you have a problem, there is no gate to signify a new note starting, so that note will be dropped.

If the process is synced to a 400Hz clock, and a note-off occurs just after a clock tick, and the next note-on arrives just before the next tick - say 2ms apart - then that process never 'sees' the gate closing! it only happens some of the time. That would cause notes to be dropped intermittently. If you have a 1000ms gap between the note-on events, make those notes only 500ms long, and make sure it's just monophonic - no chords. If it's still dropping notes, then the problem is something else.

It's hard to tell, because you haven't given much information, and you haven't posted pics of your rack or your sequence, so it's guesswork only.

xeodon

Hello colB,

Bottom line - there is some weirdness with OM to Reaktor.

First ran tests with control rate variations. No change at all. Attached are 2 screen shots of the MIDI monitor. Running thru Reaktor adds a 2nd note off about 11ms later. I then tried note-in direct to scope as you suggested. It appears to be skipping gates. I think the image captures the skip. Tried to time the scope to the playback. That image had control rate set to 2400hz. Various values made no difference. It is pretty easy to see the skips while the clip is playing below the scope. Then I ran same Reaktor rack inside Bitwig with a Bitwig clip. Got nicely timed gates. Ran Bitwig clip into loopMIDI into the same rack. Again nice clean gates. I guess my original idea is a no go but I will still try from time to time with various other OM clips to see if weirdness persists. Thanks again for your insights. Had a pleasant afternoon doing detective work and learned a bit more about Reaktor.

scope view.jpg

MIDI monitor output straight thru loopMIDI.jpg

MIDI monitor output through reaktor.jpg

bitwig-loopMIDI-reaktor.jpg

colB

Look at the midi ox timestamps

There a multiple instances of a note-off having the same timestamp as the following note-on. That means they are within the same millisecond. That's not going to work!

Can you make those notes staccato? with a dot under them? Or find some way to edit them in Open Music so that they are slightly shorter with a bit of a gap.... make them quavers, and put rests between them?

That is a compatibility problem with the output from open music. I'm not saying it's a bug, it will be just fine if sent to some polyphonic destination, but a monophonic synth will interpret that as legato. So it can be converted to Blocks format, but not converted back in any coherent way because information is lost in the conversion due to the overlapping events - it's not possible for a closed gate and an open gate to exist simultaneously on a monophonic gate signal!

xeodon

Hello CoB,

Exactly that dawned on me during dinner! I was thinking about the difference in shape of the scope triggers from OM and Bitwig and I realized I had not looked at the timestamps between note off and the next on and when I did there it was! I got so focused on the test I did not review the results...bad form for an engineer! I find it odd that it does that. Might be worth a search on the IRCAM forum.

I'll fool around in OM as well. This is like the 3rd time in quite a few years I have attempted to learn and understand OM. It intrigues me but I gave up on it a number of times in frustration. I'm hoping I'm older and more patient now!😁 Again Thank You!

colB

I find it odd that it does that

I dunno, a quarter note is a quarter note - length is a quarter note, so if you string 4 together, there shouldn't really be much gap, unless you make it e.g. a dotted 8th and have an 16th note rest...

The problem here is converting between so many formats - polyphonic notation -> polyphonic midi -> monophonic virtual CV -> monophonic midi... It's achievable, but we can't expect it to 'just work'. You need to develop a workflow and understand where all the gotchas are.