slide module - so how it works

[RJHollins]

Thanks MyCo for the clarification thread by Malc. This definitely provides a better understanding of what's happening behind the scene.

Unfortunately, the example .osm link goes to a re-direct. If anyone has this OSM:

http://www.synthmaker.com/docs/uploads/ ... 0timer.osm

I would like to see it !

Again, Thank-you for your time and help MyCo.

[MyCo]

http://synthmaker.co.uk/forum/viewtopic ... 524#p59441

[RJHollins]

You are a Scholar and a Gentlemen

Now that I can actually test the 'Slide' function as a VST plugin within a DAW environment ... YEAH !

I've now been able to tweak this routine of a MIDI controlled VCA. Although I'm still fine tuning the actual values, I now have the 'Slide' function 'ramping' values up to target from zero ... more or less a fading in of gain. Again, I need to real-world test this for the right performance.

What I'm dealing with are patches that have differing output levels. Through a 'user define' method, each patch change sends a 'compensation' value to a VCA [VST]. Of course, I cannot control the patches directly or internally , so this is my fix

There is a silence of audio whenever patches [PRGCHNG] happen, and the length of this change is variable [it seems]. But the sudden change in volume is very distracting. My goal is to find a smooth transition back to the target level.

Now that MyCo has provided the key ... I am able to proceed , hopefully, with a good working experience.

Thank-you !!

[RJHollins]

Hi MyCo ... very sorry to bother ... I've come up to a snag with the 'MIDI De-Threader' implementation

hmmm ... thought we had everything working good .......... until ..... this ...

Data coming OUT of the Midi 'SPLIT' primitive ... as long as the D2 value is different ... all is good.

However, I've a situation that [by coincidence] happens to be sending the same value as what was previously sent. This means that the 'SPLIT' prim does not send a 'trigger' to the De-Threader and the Sample/Hold sees no change.

In fact, inside TROG's 'MIDI Channel Selector' module, the identical data is being blocked ... so really, this seems the real problem area.

Maybe I'm not going about this the right way ... I need to be able to restrict this VST to only listen on 1 specific MIDI channel [user selectable via pull-down menu].

Honestly ... I'm not fully understanding how TROG has this module designed ... or maybe there has been a change coming from SM to FS.

I'm perplexed ... and a bit burned out at the moment ... maybe someone sees the problem

Thanks!

[MyCo]

However, I've a situation that [by coincidence] happens to be sending the same value as what was previously sent. This means that the 'SPLIT' prim does not send a 'trigger' to the De-Threader and the Sample/Hold sees no change.

Well, I've tested it with my controller (it's a novation SL Mk2), and after finding out how to send to identical CCs, everything was working (S&H outputs 2 triggers). Are you sure, that your controller sends repeated identical CCs? By default no controller should do this. In fact I had to setup two knobs with the same CC to be able to send it.

You could try MidiOx: http://www.midiox.com/ to see, if your PC really receives the CCs.

The S&H itself doesn't compare for value changes, so I don't see a reason, why it should block it.

[RJHollins]

Hi MyCo,

I'm trying to sus out the problem still ... please ... let me ask this

The SLIDE primitive has a 'Set current value' option. I've placed a float string on that, with a value of '0'.

What I'm trying to get is a ramping up to the 'Target' value [supplied by D2] to always start from '0' [zero].

Is there something I need to add [like a trigger or something] so that each time a 'Target' value is sent, the SLIDE will begin at 0 and ramp up to the target ???

I didn't think this was going to be such a problem actually. I must be doing something easily wrong

Maybe this is the root of the problem I'm finding.

[MyCo]

Check the attached file... I've commented in there.

[RJHollins]

Hi MyCo,

Thank-you ... the setting of the 'Slide' option is working ... and a much nice way [I'm not surprised]

I still have a problem in my schematic ... if I may, I'd like to extract this section and mod it for easier testing ... then post it to this thread. I'm thinking there is a problem in the MIDI Channel filter module that is showing up in the SPLIT module at the 'CHANGED' trigger. At least that is my suspect.

I need to pick this up tomorrow.

Thank-you for watching over me on this ! I'll put something together that hopefully illustrates the problem, while trying to minimize wasting of Your time

Sincere THANKS

[RJHollins]

OK ... hoping for a solution to this problem I've encountered

I've extracted a portion of my schematic, and had to add some INPUT routine to supply DATA. Normally, this DATA would be arriving via MIDI, but for examining I hope this makes it easier to troubleshoot. Also added a few comments to help clarify.

The 'problem' is when consecutive DATA of the same value are sent IN. The MIDI CHANNEL Filter module seems to ignore this, so called, duplication in received data [no MIDI activity lights up].

I do need to restrict the overall module to listen to a user defined, single MIDI Channel .... but I also need all DATA coming in to go through the SLIDE [ramping up from 0] procedure, even if the actual DATA value is the same as before. This circuit is controlling a VCA routine that dampens volume during a ProgramChange command in another plugin.

MyCo's technique for 'ramping' the SLIDE prim up from 0 works great. The MIDI De-threader also corrected the issue when exported as a VST. The issue I'm looking to solve does not appear to be any kind of bug, but there is a problem with the current schematic design with consecutive [same] values are received.

Hopefully there is a simple solution

Thanks for checking this out ... schematic enclosed.

Problem with duplicate data.fsm

(237.34 KiB) Downloaded 910 times

[RJHollins]

aaahhhhhhhhhhgggggggg.

ya know, ya try to do the right thing ... try to keep your triggers under control, make sure data changes actual happen ... all that kinda stuff.

I think I might have found the culprit ....

From out of my 'Send' module, I have a 'Float CHANGE' prim before hitting the MIDIEVENT prim. Seemed like the reasonable thing to do at the time

Just bypassed it, and now things seem to be working all around ... I'm still verifying.