Cableguys Midishaper

[Press Enter]

Have you looked at the resolution of the IAC midi ?
it blows.

and you can't improve it like you can with in-host midi.
Plus you can't close the midishaper gui, or it stops outputting IAC midi.

[Jakob / Cableguys]

Have you looked at the resolution of the IAC midi ?
it blows.

and you can't improve it like you can with in-host midi.

Yes. It depends on the situation if the resolution is still sufficient for you. With very fast-running LFOs or hard sample-accurate cuts it might not, for others it might still be better than required.

Plus you can't close the midishaper gui, or it stops outputting IAC midi.

That's true, and is actually kind of a bug of Ableton Live (after a while, Ableton stops sending processing requests, if MidiShaper does not output something to Ableton Live's MIDI or audio stream and if the GUI is closed). You can workaround this by putting MidiShaper on an audio channel after a running clip. But we'll release a fix soon (actually a workaround which outputs a very low noise if no other audio is running on the channel, so that Ableton Live does not stop MidiShaper). My bet is Friday evening.

[siliconarc]

i just came across the lfos stopping running while trying the demo. shame.
you say it's kind of a bug, have you reported it?
surely having to add some low level noise to the channel for it to work shouldn't be necessary, should it?

is this to do with Midishaper having to be an audio effect rather than a midi effect (which Live doesnt support... *grumble*) ?

[Jakob / Cableguys]

i just came across the lfos stopping running while trying the demo. shame.
you say it's kind of a bug, have you reported it?
surely having to add some low level noise to the channel for it to work shouldn't be necessary, should it?

is this to do with Midishaper having to be an audio effect rather than a midi effect (which Live doesnt support... *grumble*) ?

Ableton Live assumes that a plugin does not need any processing calls if it is not opened, and if it neither outputs or passes through audio or MIDI directly for a while. I guess this is clever for lots of cases and saves CPU, but in our case this means MidiShaper stops outputting MIDI to a MIDI port.

If audio is passed through MidiShaper everything's fine, and we do not add low-level noise. We only do so if no audio is passed through MidiShaper, and if MIDI is not output to Live's MIDI stream, but to a MIDI port.

[UncleAge]

i just came across the lfos stopping running while trying the demo. shame.
you say it's kind of a bug, have you reported it?
surely having to add some low level noise to the channel for it to work shouldn't be necessary, should it?

is this to do with Midishaper having to be an audio effect rather than a midi effect (which Live doesnt support... *grumble*) ?

Ableton Live assumes that a plugin does not need any processing calls if it is not opened, and if it neither outputs or passes through audio or MIDI directly for a while. I guess this is clever for lots of cases and saves CPU, but in our case this means MidiShaper stops outputting MIDI to a MIDI port.

If audio is passed through MidiShaper everything's fine, and we do not add low-level noise. We only do so if no audio is passed through MidiShaper, and if MIDI is not output to Live's MIDI stream, but to a MIDI port.

On a side note: This explains why I was having problems quite a while ago with some Sugarbytes plugs. The same thing was happening. After looking into it Sugarbytes told me the issue was on Live's side of the fence but never really explained the details.
Thanks Jakob!

[Press Enter]

it's an issue on Ableton's side, sure.
But it seems pretty straightforward for a developer to work around it.

I reported the same thing to sugarbytes, and they refuse to 'fix' it on their side. Suggesting instead to waste one of your modulation lanes, for every preset you make, to constantly send some midi data.

Jim from five12 has successfully 'beat' this bug of Ableton's quite some time ago, simply by sending a packet in the background. Sugarbytes tech support weren't/aren't interested in doing the same after I forwarded them to the thread where he menions his fix.

Lame, all around. Another game of pass-the-buck where the only loser is the end user who pays the bills.

Kudos to Jim from five12 for putting his customers first, though.
Infact he didn't even bitch about it being Ableton's fault, which seems to be the resoundingly common consensus amongst devs, he just fixed it so his software worked as expected.


@Uncleage
Please remind Sugarbytes about this issue, and refer them to the fact five12 have fixed/worked-around this simply by sending a packet in the background.

[Press Enter]

Have you looked at the resolution of the IAC midi ?
it blows.

and you can't improve it like you can with in-host midi.

Yes. It depends on the situation if the resolution is still sufficient for you. With very fast-running LFOs or hard sample-accurate cuts it might not, for others it might still be better than required.

Actually it's not sufficient on slow stuff either, where the stepping is seriously obvious.
No biggie though. If that's the best you can do, that's the best you can do.
But it's worth warning people to double-check that the resolution is acceptable for them.

[siliconarc]

once again that's Live's fault. try recording MidiShaper's output to automation - say a basic sine lfo at 1/8.

while recording, all looks good:


stop recording, Live thins the data to this:


i tried meddling with the options.txt midi thinning set to 0 etc but still thins the shit out of any incoming data, and any CCs recorded into clip modulation are stepped like crazy. pretty poor all round on Live's part, but i've gotten used to it.

[Press Enter]

I'm aware of options.txt midi thinning.

That's not what I'm talking about.

Didn't you see the post Jakob made, acknowledging what I'm referring to ?

[siliconarc]

you're talking about the cc data resolution when using the IAC bus. i don't hear any stepping, tbh.
but then i'm not testing the thing with an ultra-critical ear. i'm just mapping stuff to knobs and making cool modulated sounds, not studying the barely noticeable stepping. besides, it all gets recorded into automation and gets thinned badly anyway, so unless you're talking about live performance, where no-one will notice miniscule stepping of an LFO on a soundsytem, i don't see (hear) the problem with using IAC.

[Jakob / Cableguys]

Please remind Sugarbytes about this issue, and refer them to the fact five12 have fixed/worked-around this simply by sending a packet in the background.

We are interested in all working workarounds too. What do you mean by sending a "packet"?

[Press Enter]

you're talking about the cc data resolution when using the IAC bus. i don't hear any stepping, tbh.
but then i'm not testing the thing with an ultra-critical ear. i'm just mapping stuff to knobs and making cool modulated sounds, not studying the barely noticeable stepping. besides, it all gets recorded into automation and gets thinned badly anyway, so unless you're talking about live performance, where no-one will notice miniscule stepping of an LFO on a soundsytem, i don't see (hear) the problem with using IAC.

I'm not using an 'ultra' critical ear either. And you're contradicting yourself.
First I'm 'ultra critical' for highlighting the confirmed low-resolution of IAC midi output from Midishaper, and then you go on to say Ableton thins midi cc badly. So you've got ultra-critical ears or not ? Midi resolution matters to you or not ? You can't have it both ways.

The difference between midishaper's in-host midi output and it's IAC midi output is patently clear, both visually and aurally (depending on the material involved.) And yes, it's patently evident even when both (in-host VS IAC) midi streams are thinned by the same settings.

Anyway - stop bothering me, you are talking out of your arse.

Please remind Sugarbytes about this issue, and refer them to the fact five12 have fixed/worked-around this simply by sending a packet in the background.

We are interested in all working workarounds too. What do you mean by sending a "packet"?

He just sends a midi packet (as in arbitrary data), I'm not sure what kind, in the background.
Email Jim, I'm sure he'll explain it to you. He never publicly went into the fine details of the fix, just summarised it in the changelog.

Edit: I just PM'd you a link to the changelog where he mentions it.

[siliconarc]

blah blah

And yes, it's patently evident even when both (in-host VS IAC) midi streams are thinned by the same settings.

bullshit. show me. or keep talking out your arse.

[Press Enter]

I don't need to show you.
I'm right.
The dev knows it.

why would I want to convince a moron that the sky is, infact, blue.

[Jakob / Cableguys]

He just sends a midi packet (as in arbitrary data), I'm not sure what kind, in the background.
Email Jim, I'm sure he'll explain it to you. He never publicly went into the fine details of the fix, just summarised it in the changelog.

Edit: I just PM'd you a link to the changelog where he mentions it.

Ah cool, thank you! Yes, this might well be better than sending low-level noise.