Active Sensing filter in Scope ?

An area for people to discuss Scope related problems, issues, etc.

Moderators: valis, garyb

User avatar
valis
Posts: 7312
Joined: Sun Sep 23, 2001 4:00 pm
Location: West Coast USA
Contact:

Re: Active Sensing filter in Scope ?

Post by valis »

dante wrote: Mon Sep 07, 2020 6:49 pm This is what Im getting from the Scope MIDI Monitor (dont have MIDI OX installed). When held bend wheel fully open, there was time for one Active Sensing message before bringing the wheel back to rest position. Looks like 2 in every 3 values is skipped - maybe thats the issue. But when sequencer plays it back - maybe its filling in the missing values.
Sequencer = Reason?
User avatar
dante
Posts: 5040
Joined: Sat Nov 24, 2001 4:00 pm
Location: Melbourne Australia
Contact:

Re: Active Sensing filter in Scope ?

Post by dante »

Yeah - but same thing happens in Kontakt standalone
User avatar
jpo_midigods
Posts: 92
Joined: Mon Aug 31, 2015 3:19 am
Contact:

Re: Active Sensing filter in Scope ?

Post by jpo_midigods »

I dont see anything wrong in your monitored data, it shows standard midi pitch bend data. If you take the wheel to the maximum, then you stop there and before you move back, there is enough time for controller to autosend active sense, thats standard midi.

Scope is ordering messages correctly, it not shows the timestamp like midiOX (there is also a portable version you dont need to install on windows) but are correctly numbered. Midi Active Sensing is only 1 byte long, its not causing problems for sure.

PB full range data are 16300 units but controllers are not sending all 16000 messages... except if you move the wheel very slowly. Most controllers lets you make offsets of +-100 units so you have about 163 different physical positions for the wheel, as maximum.

If you use a 100mm midi fader like the BCF2000 you get more precise control at your fingers but remember Pitch Bend Wheel is the most used way to articulate sounds on keyboards, and your VST is expecting standard pitch bend data also. No need of conversion, just see midi configuration options for the guitar synth - cheers,
"MIDI is the languaje of Gods" (anon)
dawman
Posts: 14368
Joined: Sun Jul 24, 2005 4:00 pm
Location: PROJECT WINDOW

Re: Active Sensing filter in Scope ?

Post by dawman »

Dante, my Physis K4 triple Wheel assembly is being replaced as we speak.
I’m buying the ISW when it’s finished and will mess with this.
PBend will be for an octave, then Wheel 1 will be -1 whole step, and FC7 expression +1 whole step.
I have calibration diagnostics and we’ll see how mine works.
If there’s any problems I will speak to Andrew and Mario.
Faxi might even know of a Kontakt script that can be made.
Either way we’ll get to the bottom of this before weeks end.
User avatar
dante
Posts: 5040
Joined: Sat Nov 24, 2001 4:00 pm
Location: Melbourne Australia
Contact:

Re: Active Sensing filter in Scope ?

Post by dante »

Awesome thanks Dawman. I'm interested not only if the problem doesn't occur on your revised rig, but if you can reproduce it on very basic rig. Also whether the CC come out consecutive or in increments from your wheels. If theres issue on yours then 1 octave range should bring it out.
User avatar
valis
Posts: 7312
Joined: Sun Sep 23, 2001 4:00 pm
Location: West Coast USA
Contact:

Re: Active Sensing filter in Scope ?

Post by valis »

Clearly Reason & Kontakt aren't applying any filtering to live input, but on playback are interpolating between values. If you're dealing with native plugins this makes sense as the data being passed would be much higher (time-base) resolution than a midi datastream, whereas passed to an external instrument via midi it's of course likely the same.

In addition, plugins may handle the live input differently than buffered playback, where it has the chance to request data 'ahead' in time and filter it to 'smooth' it out. Typically a 3db filter or slew filter is enough, though this can 'lag' a single-sample automation a tad, it's often preferable to the 'stair stepping' you seem to be hearing. Hence my recommendation to try doing the same in a mod shell before passing the data to your plugin host. Most of the newer synths I've played with handle most/all data both from the front panel and via midi in a similar fashion btw, since about the Virus A era/JP8000 onward it's been fairly standard.

In Logic and other DAWs that I know well, i know the time-based length of automation data types, classical "TBA" or mixer & plugin style "track based automation" has a length that it precalculates for data when *playing back* automation, so that the way it ramps between 2 values is very distinct in audible effect. The most noticeable effect to the ear is on attempting to do single-sample value ramps (no volume to full, or closed filter to open). Not only do you have to get it 'early' enough that any slew filtering has time to 'fully open' but in most of my DAWs I find I have to also get the value on or before the 'data block length' change, so that it's calculated in with the next block. On testing with Logic Pro 9, the 'medium' size for the mix buffer would be about 512 samples for block length, and this affected the way automation was handled as well as CPU load. The Process buffer was similar, though quite smaller, and so if you had a track 'selected' and thus in 'live' mode (the smaller "process buffer" size is used for that audio chain from track to most downstream busses), those value ramps could be noticeably off. Either too early or too fast, compared to when the track was not selected. Suffice it to say there's a few layers that you can think of as 'quantizing' in a time-based that might shift a data point or value ramp, and then depending on whether you're handling live input or playback things will again change in MORE than one way. LPX seems to have halved the blocksize btw, but I haven't updated since 10.3.x so not sure what's going on at present.

In testing, Cubase was similar though it used a shorter 'length' blocksize in the cases we tested then, and same for Studio One 2 (last time I paid attention to this issue).

How Kontakt in standalone might handle this, as well as Reason, I'm not sure. But I'm not surprised you find a difference between live input and otherwise, the question is how to 'solve' this for playing in a way that matches playback close enough, as I hope my example indicates.
User avatar
dante
Posts: 5040
Joined: Sat Nov 24, 2001 4:00 pm
Location: Melbourne Australia
Contact:

Re: Active Sensing filter in Scope ?

Post by dante »

Well, if I want a bass guitar to go down to Drop D but the particular VST doesn't support drop D then I cheat and use pitch bend on an bottom 'E' just before the note start that goes from 0 to -8000 in no time at all, then back up when note ends. That normally works without ramping or other artifacts.
User avatar
jpo_midigods
Posts: 92
Joined: Mon Aug 31, 2015 3:19 am
Contact:

Re: Active Sensing filter in Scope ?

Post by jpo_midigods »

Thats ok Dante, you are telling the synth you want the note bended down to the maximum, thats usually 1 semitone (2 for the entire range) by default on most instruments and users can change it to up to 2 octaves or more, curves, stepping and more. This is basic configuration for emulation of any traditional instruments using just a simple midi keyboard.

I think Valis is correct and daw and/or instrument is enhancing the midi recorded data at playing time since events are known before playing and can be preprocessed saving resources for i.e. polyphony.
"MIDI is the languaje of Gods" (anon)
dawman
Posts: 14368
Joined: Sun Jul 24, 2005 4:00 pm
Location: PROJECT WINDOW

Re: Active Sensing filter in Scope ?

Post by dawman »

Add a week to my ETA on the Physis K4 being returned.
He is just now getting the schematics from Viscount/Italy.
User avatar
dante
Posts: 5040
Joined: Sat Nov 24, 2001 4:00 pm
Location: Melbourne Australia
Contact:

Re: Active Sensing filter in Scope ?

Post by dante »

Cool. So what do you assign the 3rd wheel to normally ? Leslie Horn Speed ?
Post Reply