Note Detector

[Candle]

Thank you for the idea, nathansnider. I just tested that out and it should work for what I'm trying to achieve

See You In The Shadows…

[wde]

0.5

• Send note off fix

[Candle]

Me again, sorry…

So I'm still playing around with my "Live" Buzz setup. I am trying to get my guitar to control a number of VST synths. Of course, I'm using Note Detector to make this work. The problem I'm having is getting the VSTs to sustain their notes when triggered by notes from the Note Detector. I have attached an example BMX - as well as a link to download one of the free VST-i synths I'm using (the amazing STS-33 by HG Fortune). The BMX is a sort of "troubleshooting" file that I've used to isolate the problem. It uses the FSM Infector as a stand-in for my guitar as the initial audio source. The Note Detector sends its note information to an IX Split which then sends a MIDI Note to the STS-33. I've used a pair of Jed Shiva meters to monitor the signal flow to see the audio in real-time.

Now what I'm trying to achieve is this: when you play a note normally with the STS-33 it usually sustains until it receives a new note on message or you press stop in the song. However, when I trigger the STS-33 (or similar synths with sustaining pad sounds), the note only sustains for a few moments before stopping or fading. I think the Note Detector might be sending some sort of note off message when it no longer detects any incoming audio. I've set the Polac VST loader to not accept MIDI Note Off messages, but this doesn't seem to help. I've also tried gating the incoming audio going into the Note Detector, thinking maybe conflicting Note messages are to blame - but this also does not seem to work. So I am at a loss. Any help or input is greatly appreciated.

Here are the files:

Troubleshooting BMX (Dropbox Link)

STS-33 Download

See You In The Shadows…

[IXix]

The Note Detector sends its note information to an IX Split which then sends a MIDI Note to the STS-33.

IX Split doesn't send MIDI, it sends notes as if they were input from the pattern. It's a subtle difference but it may be the source of the problem, so I suggest trying without Split to see if it works properly like that.

Split needs an update. So many things to do and only one me.

[Candle]

Sorry, I was tired last night & got my explanation a little jumbled. Note Detector sends the MIDI Note Data. Split "translates" it to Buzz Note Data (Peer Note). The STS-33 (& all of HG Fortune's amazing VST-i's, unfortunately ) do not accept MIDI Note Data. If they did, I'm not sure how it might help (see below re: polyphony). I need Split to "translate" the MIDI Data to Peer Note Data, so getting rid of Split isn't an option. I just tried sending Peer Note Data to the STS-33 from Magic & that works (the notes sustain as expected). I also tried sending a Peer Note from Magic, through Split & to the STS-33. The note sustains via this routing as well. So it doesn't look like it's Split causing the problem. It looks like it's Note Detector.

I think that if Note Detector detects any audio level (above its set parameter threshold), it cuts the previously transmitted Note (sends a Note Off message?) & then transmits a new Note On message (or perhaps simply replaces the old Note On message with the new). It's essentially a MIDI polyphony problem, I guess. The old Note is cut to allow the new Note to be played (monophony - for lack of a better term?) . There is no way to allow the old Note to fade while the new Note begins to play (polyphony).

I tried to get around this by putting a Gate in front of the Note Detector (to minimize ghostly "flam" notes). I've also played around with the Note Detect threshold, but it doesn't seem to change anything - or I can't find a setting that works In the end, my idea of triggering synth pads via my guitar doesn't seem to work - at least not with the current Buzz Machines I'm using. So I guess if anyone has any ideas of how I can get this working, or has any suggestions - I'd be really grateful

Thanks in advance

See You In The Shadows…

[Candle]

Split needs an update. So many things to do and only one me.

We can only do what we can, IX. And you do a lot for Buzz & the Buzz community. Don't beat yourself up

If I knew more about coding beyond:

10 Print "Candle loves to Rok with Buzz!"
20 Goto 10

I'd love to help out. But, Buzz isn't coded in Basic

See You In The Shadows…

[IXix]

I need Split to "translate" the MIDI Data to Peer Note Data, so getting rid of Split isn't an option.

Not to hijack the thread but Magic will do that too. PeerCtrl Event with note param = "Pass", velocity param = "V". You could then monkey about with delaying/ignoring note-offs. It can do the same note/velocity range splitting that IX Split does but it's not so easy to set up and of course the more complexity you add, the harder it is to figure out what's gone wrong when it doesn't work.

PM me if you have any questions.

[HerrFornit]

Also a very nice machine !!
I always get a latency between note sending machine and the receiving machine, getting notes by note send. It in the range of ca. 100-200 ms or so.
Why is this?
In this example the guitar is driven by your GuitarChordBox, NoteDetection sends to 4FrontPiano. Get latency in other setups (non-vst too)and with any threshold, too.

NoteDetector.jpg (29.53 KiB) Viewed 13295 times

[wde]

Also a very nice machine !!
I always get a latency between note sending machine and the receiving machine, getting notes by note send. It in the range of ca. 100-200 ms or so.
Why is this?

The algorithm needs some audio data before it detects the note. That introduces latency.

[HerrFornit]

The algorithm needs some audio data before it detects the note. That introduces latency.

OK, I see. It is a matter of DSP then. You need a certain minimum window? The shorter the window the less secure is detection? Could be a kind of speed parameter of NotDetector ?. I tried to have a live second voice, that would need max delay of 20 ms or so?
By the way, what is the unit of thresholds ?

[wde]

I don't know how the algorithm works. There are some discussions here. Detection level min = -80dB, max = 0dB.

[HerrFornit]

thank you. OK its an external algorithm. In the discussion you linked I have found:

"The description says the algorithm can detect up to 3000 times per second. However, looking at the source code, the PitchRecordsPerSecond property seems to be capped at 100.
Thread #644743 | Message #1443664 | 2015-09-08"

According to that it should give out at least with 10 ms delay. Hard to hear. Perhaps its also a matter of audio buffer?

The number of samples is derived from the sampling frequency and the minimum detection frequency. If you look at PitchTracker.Setup, you will see a formula that is used there to calculate m_pitchBufSize. In addition, there is also a m_detectOverlapSamples value that is also calculated in that method. That value is added to m_pitchBufSize. For 44100 samplerate and the default 50Hz min frequency, these values correspond to 1780 and 220, so the minimum required samples is 2000.

It should be easy to add a property like PitchTracker.MinRequiredSamples that simply returns m_pitchBufSize + m_detectOverlapSamples. There is already one called PitchTracker.DetectSamplesOffset that will return half that value, which is used to calculate the offset from the input signal to the detected value (which can be used to sync up the detected pitch with the passed in waveform). If you don't want to add a new property, then PitchTracker.DetectSampleOffset multiplied by 2 will give you the minimum number of required samples.

2. You can clear the buffer by calling PitchTracker.Reset(). You can't disable the feature, since it is an integral part of how PitchTracker works. If you are always going to pass in one large buffer, then one can certainly modify the code such that it doesn't use the intermediate circular buffer. But this will require a lot of changes and I don't think a lot of people would really need that. If this is something you absolutely require, then you would probably need to make the changes on your end.

3. No, the data is filtered and copied into the intermediate circular buffers. The data in the original buffer is untouched.
Thread #349823 | Message #815017 | 2012-03-24

[Candle]

OK, so I'm still trouble shooting my Guitar -> Note Detector -> Magic -> VST signal chain. Magic has simplified my process (thanks IX ), but the notes being sent to the VST synths via Magic are still being cut. So I drummed up another "Troubleshooting" project to isolate things. I used PrimiFun as the initial Audio source for Note Detector & had Magic do the "translating" from MIDI Note Data (from ND) to Peer Note Data (sent to the STS-33 VST synth). I then opened up Magic's MIDI message screen (a really handy feature when troubleshooting things like this!) & saw right away that ND sends Note Off commands. See attached screen shot below:



Is there a way to have Note Detector not send Note Off commands? Perhaps an Attribute selector to choose between "Send Note Off = True" & "Send Note Off = False"? I am sure there are situations when either setting would be helpful.

Thanks in advance!

See You In The Shadows…

[IXix]

OK, so I'm still trouble shooting my Guitar -> Note Detector -> Magic -> VST signal chain. Magic has simplified my process (thanks IX ), but the notes being sent to the VST synths via Magic are still being cut.

Not to hijack the thread again but have you tried setting the relevant Magic Events to ignore note-offs? If that doesn't work then the notes are probably being cut by voice stealing, in which case you could try adding more tracks to the VST machine, or try limiting the range of target tracks used by individual Events to avoid clashes. PM me if you have any questions.

[Candle]

I thought of that & set the Magic Events to ignore Note Off Messages. I'll PM you with more.

See You In The Shadows…

[River Cricket]

Yet another amazing tool from the mighty wde

Would it be possible to add a "range limiter" to this to help clear up the occasional obviously-incorrect note (and also make it a bit more capable of handling isolated instruments from full-band material)?

We can already kind of futz our way into this by routing audio through a bandpass filter, but allowing Note Detector to do this on its own might be cleaner. Something like:

Analyze Audio
Get Note
If Note <> Range, ignore
Else Send Note

This way we don't have to precisely tune a bandpass filter to get rid of audio outside the desired octaves - instead, Note Detector does its own decision-making based on what note it's assigned to the current slop of audio under its own parameters.

(I guess there's obviously some Peer Machines that could ignore all notes outside "Range", but hey, sometimes a bit of redundancy is nice to have a bit of redundancy is nice to have a bit of . . . )

[wde]

• Send note off (or not)
• Lowest/Highest note to send