piz midi plugins (windows/linux/mac)

[insertpizhere]

So far it seems alot friendlier on the buffer underruns than my previous bidule mixer feedback release method though I am wishing that midiCCreset was able to do only transmit CC values that had changed since the last preset used.
This would ensure a very low likelyhood of popping sounds when changing high channel count scenes.(I realize it does in fact already do this sort of but I have to send each preset default values from my host for all mappings on each preset or else adjusted values do not revert by themselves)

A 'smart' CC value filter would be perfect!One that would monitor all incoming CC values and then only pass through what had changed during the session...

that would be easy to add as an option, and could be good as a separate plugin as well... i'm assuming you mean it would remember every CC value it sends and block any that are identical to the last sent value.

A mute midi thru would be good too because I am unable really to avoid sending all my realtime controller CC's to my host twice when using midiCCreset for two different tasks at once..

this would also be an easy addition... do you mean it would block everything and only send CCs when triggered? i usually add a few different thru modes, but i haven't actually used this plugin myself, so i'm not sure what would be useful.

Anyways, just shot you a few bucks via your broken paypal donation button on page 1...much appreciating all this cool plugs! Thanx!

thank you!

[gurulogic]

that would be easy to add as an option, and could be good as a separate plugin as well... i'm assuming you mean it would remember every CC value it sends and block any that are identical to the last sent value.

That is exactly what I mean, assuming it could actually work in context with presets (captured scenes) .It would look something like this I suppose:

Init:
1 CC (1) 0
1 CC (2) 127
1 CC (3) 0
1 CC (4) 64
1 CC (5) 32

scene 2:
1 CC (1) 0 XX
1 CC (2) 127 XX
1 CC (3) 0 XX
1 CC (4) 127
1 CC (5) 127

scene 3:
1 CC (1) 0 XX
1 CC (2) 64
1 CC (3) 32
1 CC (4) 127 XX
1 CC (5) 32

In the case of a seperate plugin it would remember all values last passed through it and only allow new new values to pass..wouldn't want the buffer saving with the host though.
Hmmm...I'm having a hard time wrapping my head around whether it would work
ok with just filtering based on a previous burst of CC values or if it would have to keep the 'init' values first sent from the host as a constant reference to add and subtract from..?

I might be the only guy to ever find this usefull, but it sure would be an awesome way to tame midi bandwidth choke issues!

this would also be an easy addition... do you mean it would block everything and only send CCs when triggered? i usually add a few different thru modes, but i haven't actually used this plugin myself, so i'm not sure what would be useful.

Yep, just a switch to block realtime midi data from passing through the plugin.
There might be a chance yet I can better combine/route my CC scene capture device and CC "realtime feedback relay" device so they share a common output to host and I don't get double CC's (+delay) but it might not works as is because the scene capture device uses a chain of midi delays on the output to stagger the data being sent to host...realtime midi block would be better.

edit:nope, I am kinda hosed without midi thru blocking..

[insertpizhere]

okay, this now has a thru switch and an option to not send duplicate values on preset changes:
http://thepiz.org/xt/midiCCReset.zip

and this just "cleans" incoming CC values of any duplicates:
http://thepiz.org/xt/midiDuplicateCCBlocker.zip

[gurulogic]

Wow you are quick and I am dumbfounded !
A quick test with the updated plug and a midi monitor shows it working exactly how I had hoped it would.This is going to make life so much better!
Unfortunately the new build kinda broke a sixteen instances group that I just finished rebuilding from the last update...well, broken in the fact that the presets that I don't even need for that groups functionality don't show on the plug but the presets can still be exported to the bidule group gui...I dunno, is it safe to use this way..?the plugin seems to be working fine but my gut tells me to rebuild again but oh the hours and parameter etc. exporting/naming/linking..
I guess now that I am comfortable with midiCCreset dealing with tons of CC's at once there shouldn't be any reason I couldn't rebuild with just one or two instances but ya know, if it aint broke...

I'm sure you know, but just in case not, midiCCreset and duplicateCCblocker share the same ID so I wouldn't be able to use em at the same time.

Thanks! No more requests..I am totally appeased

[insertpizhere]

I'm sure you know, but just in case not, midiCCreset and duplicateCCblocker share the same ID so I wouldn't be able to use em at the same time.

no, i missed that. fixed: http://thepiz.org/xt/midiDuplicateCCBlocker.zip

[gurulogic]

It is great how you made midiDuplicateCCblocker only block duplicates until a value change has occured, then it allows the blocked value through again!
I was worried that it might just block any duplicate values forever.

As a suggestion, midiDuplicateCCblocker could be made a little more interesting by giving it the ability to block duplicates of other midi data types, ie:note on/note off and Program Change.

Just to throw a vague idea at you of something that's been turning around in my head for some time that I personally have no way of making happen unless I maybe build something insanely complicated in bidule..
What I'm thinking of is something like a midi drum arpegiator but I guess it would be better described as a multichannel variable drum groove oriented midi delay/repeat.

Abstract: an 8-16 channel midi delay line where each group of notes fed into it would be automaticly split low to high across the channels. Each channel would have controls for variable grid based delay or repeat, repeat duration, time signature, note retrigger, retrigger "variator", retrigger density+value, note cut, note cut "variator", note length, note length "variator", swing, offset per row, offset per beat "variator" and even a beat randomizer based on grid and time signature.

"variator" refers to being able to pan through the duration timeline to select which beat gets affected. "variator" off would affect the entire row except perhaps in the case of offset per beat as it would be nice to adjust row offset and beat offset individually.This may also apply to note length.
Also maybe a "lock" function for each "variator" selected edit so multiple variations could be set in a single row.

I don't know if something like this is your cup of tea, but if so, I fully release any supposed intelectual rights into your adept hands for safekeeping

[insertpizhere]

As a suggestion, midiDuplicateCCblocker could be made a little more interesting by giving it the ability to block duplicates of other midi data types, ie:note on/note off and Program Change.

yes, i might as well let it affect any type of message.

Just to throw a vague idea at you of something that's been turning around in my head for some time that I personally have no way of making happen unless I maybe build something insanely complicated in bidule..

i'm not sure if i totally understand the idea, but it sounds like a combination of several concepts that are used in my existing plugins. midiProbability, midiSwing, midiStrum, midiDelay, midiPolyphony, etc...

it would certainly be complicated, but you may want to investigate those if you haven't already... particularly the beat-based channelizing feature of midiProbability, which (i think) is similar to the "variator" concept.

[gurulogic]

i'm not sure if i totally understand the idea, but it sounds like a combination of several concepts that are used in my existing plugins. midiProbability, midiSwing, midiStrum, midiDelay, midiPolyphony, etc...

it would certainly be complicated, but you may want to investigate those if you haven't already... particularly the beat-based channelizing feature of midiProbability, which (i think) is similar to the "variator" concept.

Funny thing is I haven't even looked at those plugins yet. It sounds like I ought to!

My idea is based on a personal wish of mine that instead of painstakingly drawing in midi with a mouse for drums, I could feed a single note, tweak some knobs and sliders and come up with locked to specific parameters beat variations at every turn of a control.Same for instruments I guess.
This need has been somewhat fulfilled by my Monome+apps but it doesn't always encompass that instant-creativity turn a knob and pattern variations start emerging satisfaction I sometimes crave..Just wishing for a differerent kind of easy on the brain realtime sequencing interface I guess...

I suppose I should start jacking a bunch of your midi plugins together with a midi matrix and remote midi controllers and see what happens...

[Optomadic]

My idea is based on a personal wish of mine that instead of painstakingly drawing in midi with a mouse for drums, I could feed a single note, tweak some knobs and sliders and come up with locked to specific parameters beat variations at every turn of a control.Same for instruments I guess.
This need has been somewhat fulfilled by my Monome+apps but it doesn't always encompass that instant-creativity turn a knob and pattern variations start emerging satisfaction I sometimes crave..Just wishing for a differerent kind of easy on the brain realtime sequencing interface I guess...

This statment screams Live mode in eXT1.41. Although you still would have to put together the sequences themselves or you could make one and then duplicate the arrangment then add a subtle change, control that via Live mode and record it all into another eXT instance.

I suppose I should start jacking a bunch of your midi plugins together with a midi matrix and remote midi controllers and see what happens...

And trust me.. a lot will happen ! I've been experimenting with IPH plugins as virtual generators with much success..

[insertpizhere]

another thing to check out would be the various algorithmic midi generators/sequencers from xoxos.

[gurulogic]

Hi piz,
I'm having a bit of trouble with the midiprogramchange plugin as it does not reliably transmit bank select messages. My workaround is to run two instances, the first one sending the bank select message and the second one is delayed two milliseconds before sending the program change message. Perhaps a delay built into the plugins program parameter would help? Also, the labels on the right are not updating when changing presets + also not a huge deal but I always get confused trying to remember that 1 is 0 etc.

edit: to clarify the labels not updating, I mean the furthest right display that shows actual values. The parameter value boxes (ie: 0.196078) are updating but it is hard to look at a newly selected preset and see what the actual value is.

[insertpizhere]

good point, i will add a delay between bank select and program change. maybe a user-selectable delay, since the needed time would depend on the destination of the messages...

i can probably fix the labels too. looks like the bidule demo got updated, so i can test it there.

edit: on second thought, the labels not updating appears to be a bug in bidule.

[Optomadic]

I'm sure you know, but just in case not, midiCCreset and duplicateCCblocker share the same ID so I wouldn't be able to use em at the same time.

no, i missed that. fixed: http://thepiz.org/xt/midiDuplicateCCBlocker.zip

Hmm havent had time to try this one out. Is there a chance you could also make one for notes? Or does this also block note duplicates?

[insertpizhere]

in fact i did make a more general version that blocks other messages, but hadn't uploaded it yet: http://thepiz.org/xt/midiDuplicateBlocker.zip


also, here is midiProgramChange with 2ms delay between bank & program messages, as well as some bug fixes: http://thepiz.org/xt/midiProgramChange.zip

[Optomadic]

Thanks piz will give these a go today !