avantronica's Recent Posts

With granulator Rate set to zero it was possible to play through the sample linearly (and loop it)

It is not possible to modulate any of the rate dials when they are set to zero, so i don't see the harm in preserving that option as a special use case .. it adds functionality

I can see no way to play through the sample linearly now, i made quite a few patches using that. Could that linear playback be implemented by another means ?

Also any thoughts on the quantisation issue posted above ?


EDIT: Just tried latest beta and the Linear Playback is back - great !

Feeding the granulator with a Trig allows you to do other stuff to the sample and to feed it through the resonator

I should have pointed out that the above was for Aalto AU in Max on Mac fwiw


Re Kaivo

A lot of presets i had which were functional in the last release are no longer functional . these exploited the previous behaviour whilst rate was 0.00

I also note that when changing between presets which both share a Rate of 1.0, the rate dial will momentarily jump up to 220 for a split second then revert to 1.0, it is interrupting audio

Has something fundamental happened in this area to result in the change in behaviour between the last release and this beta, do these observations make sense ?

I think i'll revisit the last release to see why i'd programmed them that way

One other comment, i'm curious, has anything changed with regards to the output of the sound engine in a manner which might affect the tone, something isn't quite right with my presets, i can't quite put my finger on it .. a little bit tamer, i looked through quite a few of my presets and was wondering if the timbre settings had been rolled back somewhat

Well, that's a bit awkward, i've clearly managed to nudge the attenuverter .. it's a common issue with the way i hold the magic mouse with fingers hovering above (and too close) to the sensitive virtual scroll ! That accounts for the octave coming in at 11, so that aspect can be put to bed. Glide was off fwiw.

A quick look at the situation as it is puts it back closer to the way it was before (whilst mousing a slider now seems to take it to its Max i.e. no need for scrolling the last %)

So, fwiw, in terms of the friendliness of the quantising from an end user's perspective i noted the following

with a Range covering the first octave each way in semitones

those with the symbol are all quantised down a semitone

+12▼ +11 +10▼ +9▼ +8 +7▼
+6 +5 +4▼ +3 +2 +1▼
-1 -2 -3 -4 -5 -6
-7 -8 -9 -10 -11 -12

same with +24,+36 and so on all ▼

This was one of the issues i raised before about 'expectation' from the quantisation, so without knowing if the strategy i suggested has its own issues, it would at least circumvent these issues

The current quantisation isn't predictable imho, based on the observation above

^ you'll need to open that image in a new tab, clearly scaled too large by default

maybe randy can scale it down for a preview inline

Clearly there's been a bit of work in the area of the sequencer, quantisation and range .. no doubt this is a nuanced issue, however, this strikes me as wrong or significantly counterintuitive

Currently if you start from scratch and only connect the seq output to pitch then there's a significant change (explore by dragging the slider fully up/down)

Previously +12 would give you an octave range, now to get an octave range you have to add 11 (or -11)

Quantization is working at the extremes, but is creating problems in smaller ranges due to the algorithm used

Try +1 and note that quantisation makes no difference, it doesn't quantise
Try -1 and you see that quantisation is immediate as you rise from zero

Try +6q and +7q ... they both behave the same, they both have only 6 additional pitches

Clearly there's a +1 or -1 issue in an algorithm somewhere because by the time it gets to what should be an octave it is gone askew .. well, maybe not so clearly, but something is amiss partly with the quantise which may be a tricky area to get right but also to the range

Maybe this graphic can help explain, in my opinion it ought to be possible to have a consistent range and predictable quantise points so it works well for quantise on/off

Suggestion

You can see in this example that to hear an octave range you need to hear 13 distinct frequencies, but to achieve an octave in the beta, you only hear 12 distinct frequencies in total, so the quantized steps cannot be in semitones in the beta

I hope this sheds some light on it, i’m glad there’s been some movement in this area (yay, at last), but there’s clearly an issue or two at play

https://youtu.be/U3pZpe2PUpM

It's best explained by following the video

Basically, the longstanding issue which affected using the seq offsets with perhaps a mod wheel would result in an effective wrap around of the pitch part (sliders) of the sequencer - however, the transport indicator would be elsewhere

very misleading and sometimes inconsistent, but essentially manifesting in this way .. this general issue seems a bit improved (perhaps) wrt using Modwheel to scan through the steps, but as can be seen here, it's not right

Really looking forward to a fix for this ..

between this and the other associated glitches that make the sequencer hard to rely on (e.g. bipolar modulation of step offset position will potentially not show the sequencer trace that is actually being played but not shown, confusingly )

Another issue is that if the sequencer range is set to +24 and you have seq steps at min and max respectively, it will play 2octaves apart when quantise is off - however, at the moment quantise is enabled - it will drop a semitone off the top value, so the range is reduced effectively to +23 - this strikes me as another bug - it makes relying on sequencer behaviour impossible and is problematic for me as i want to program an external sequencer to sequence it, but it can't happen until this is fixed, just like sound design

it sounds fantastic and is fun, but it's not consistent wrt the UI and it's been this way for a long time now, really hoping for a fix or feedback on this one

ah .. 'after' .. , my heart read 'for' somehow

Hope it's not too long then, it's been there quite a while and it pretty much puts me off leaning on the sequencer as i know it should be subject to change .. perhaps videoing a patch before an update is the only way to replicate the same design after it if it's corrected to be consistent

fingers crossed

This behaviour is still the same.

It is not possible by mouse dragging to achieve the quantised high value you expect, it is still necessary to scroll the last % using a mouse wheel, this is very counter intuitive as it stands.

https://youtu.be/oh1TLcfE2QQ

This is a bug that affects Mousing in a quantised sequencer used for pitch

It is necessary to use the scroll wheel to get the expected range because it is not possible by mouse alone to achieve the highest value (even though it looks maxed out)

It is explained in the video comments

Bug first reported 20months ago in Feb 2015 circa 1.6, possibly always there, i'm not sure (more detail provided in that email report btw)

I believe this may also affect Kaivo, i haven't checked this at time of posting

Hopefully this can be resolved, it is easy to conceptualise and repeat unlike some other nuanced issues

apple have positioned themselves in a place which makes it very hard for me to respect their business model these days, it's always welcome to hear of these stories of 'life going on' post-apple (particularly, if like me, that seemed impossible at one point)

hopefully a tipping point has been passed and other developers will be as enthusiastic about supporting other platforms too, that gives us all a bit more choice and promotes competitiveness again but apple won't need to look out for the creatives who probably kept them afloat when times were toughs their money comes in from many other directions now

https://youtu.be/szQBAm0VzYc

Hopefully self evident .. when the voice is 1 the seq trace will wrap around, when it is non-1 it will show partial traces for the extra voices leaving lots of unlit (but sounded) steps (also possibly glitchy/freeze when voice count is raised prior to restarting all voices)

Seems to be a new UI trait in this beta iirc, further comment on video

i'm not sure what's more sobering, no replies or only 8 views in 5 weeks for 3 bug video reports (3 & 2 views respectively on the others !), either way it doesn't bode well for getting support for these points or even to get them fixed .. it's fairly quiet here, and without footfall or feedback, it self-perpetuates which can't be in anyone's interest and makes it of questionable value to continue to offer feedback .. it certainly dents the enthusiasm to engage with it

This point is only about visual feedback, the other posts of mine which have no replies are about patching inconsistency, that should really be catching everyone's interest

A useful forum needs a bit of contribution from the community as well as the administration to build and sustain a momentum .. 2 views after 5 weeks for a video demonstrating a bug is a pretty disheartening statistic

To my ears, it's not that different to the internal sequencer (env1 set to seq) (if run at the 1.5 to 2.0 rate, so circa 30>50ms midi interval even)

Did you try turning on Overdrive ? Maybe take off the animations in Aalto too

Even with snappy envelopes it's quite tricky to monitor jitter (for me anyway) if the timing is nearly right in the 80ms interval region .. when set to 100ms plus, it's easier to gauge the consistency (unless bad) to me it seems not too bad .. but obviously when you patch with max it gets interrupted

might be worth comparing Aalto with a lean vst set with a snappy click sound

you may find that mousing the slider to the top doesn't actually push the value to the max .. I reported this, it's apparently fixed for the next release, to get the slider to the max you'd use your mouse scrolling wheel (even though it looks Maxed out it isn't)

from my explorations, I've had no problem getting an octave with +12

I should add, the sequencer UI mismatch for the sliders is often intermittent, I previously sent in a procedure to show how or ensure the slider was aligned with the sequencer indicator with a hope this would illuminate why it was not consistent .. so that may explain why it works as you'd imagine (as it has, just now, for me) .. plus, the patch has an arbitrary error in that it is ordered wrong (in right to left terms) for the initial setting of the rate etc (nothing major, just flagging the flaw)

glad the offset workaround is offering a way forward

it would be good if there was a key advance mode for the sequencer, a common technique on some synths

I'm curious about what the intention was here too, but from my perspective, it seems straightforward if you're within Max anyway to either jump to a specific step or to step through the sequencer in order.

As suggested by Randy the Sequencer Rate is 0 so will only advance on an event from Max, either from a specific step int ( 1 to 16 in attached patch ..refer to img) or through a bang or any other route you want to take to position it

However .. if you do this you'll see that there is a bug whereby the sequencer will play step N-1 (or it will play step 16 when 1 is selected) .. this is a longstanding issue i've raised a few times now .. the blue 'gate values will be aligned correct, but the corresponding orange seq step will be off (although Randy hinted it may have been bottomed out in the upcoming release with the new license arrangement ) (PS same in Kaivo)

StepThroughOrDirectInt.png

A few other previously mentioned little 'non-showstoppers' but may be easy to rectify before next release ..

A) A few presets launch with 'No Oscillator selected' - see example

B) A few presets report spurious value for delay (20ms as opposed to 50ms minimum)

C) Quite often it is disconcerting when an activity led is firing when there's no actual input, maybe there's good reason to assume a pitch of 64, but i think the default should be 0 until pitch is detected and then report, likewise having peak indicate that there is a signal when there isn't just muddies the water imho - tiny things, but hopefully easy to rectify : )

UI errors.png

Just saw this new beta ^
The issue I reported where the cabling will self-destruct if clicked is still present

For the connections from the Key block into a trig inlet it seems to work by displaying the nodes once clicked

When I click e.g. Mod to Shape it will not display the nodes it will just zap the cable, this makes it tricky to edit as it can lead to erroneous deletions quite quickly

I connected two elements together, did not like, tried to click then deselect, but it automatically deletes a prior good patch cable !!

Either way, this UX behaviour is different from Aalto and Kaivo

https://www.youtube.com/watch?v=-7e69mVaJnw

The above linked video illustrates some issues with buffer clearing that can lead to very unexpected outcomes. I've tried to add a few words to the comments. But basically, there can be a lot going on when you could reasonably expect there wasn't, buffers and voices retain a presence and can re-appear depending on a few factors. In this example three different samples can be heard within the granulator and voices from earlier in the session can be reintroduced - suggesting that voices aren't being cleared in a manner you might expect - i.e. when presets change, possibly unexpected when samples are changed and really unwelcome when a voice count is raised to reveal older occurrences still happening. This is a very controlled demonstration of a phenomenon which can be even more unpredictable. Please note that when the preset changes to one with a low voice count the dials on the sequencer and sequencer still show the details for an eight voice patch, even though only one is selected - plus even with one voice we are able to load up three samples confusingly and also revisit earlier material when the voice count is raised. Hope this helps get to the bottom of it. I'm happy to be advised about those aspects which are intentional or misunderstood.

I am aware that some aspects of this actually relate to grains as opposed to complete voices. There will be use cases where unusual outcomes are unavoidable I'm sure, but some of the aspects (especially concerning preset changing or voice count) seem more like little housekeeping things which could be tidied up.. I'm aware that this relates to a 'special' case where rate is 0

I do have a few user thoughts on this aspect of Aalto and Kaivo; it's a bit challenging sometimes to dial in the lower values close to zero .. e.g. in Kaivo, I have on occasion been able to set the value to 0.500, but it's a very tricky process to get the slowest rate without setting it to zero

Sometimes I long for a way to disarm the rate more obviously (i.e. set to 0 effectively) without tweaking the dial .. another aspect of the rate=0 dial position (as opposed to an over-riding button) is that it precludes modulation input .. this preclusion often throws me because there are no visual clues that you've effectively turned it all off .. I'm not sure if I can offer an explanation that would account for the modulation input being neutered (except if the modulation was factoring zero, but in that case it'd be okay IMHO to work from the lowest valid value as though the dial were just above zero .. so that modulation was still permissible) .. the behaviour may also be intentional

Edit: modulating the rate whilst at zero is not such a clear cut issue as such, still interesting to reflect on this relative to user expectation that the modulations could be applied

This is also an issue with Aalto

https://youtu.be/r4bGCs1Mhaw

refer to notes on video, but basically the expected value and the UI reported value differs from what is happening. This is just a simple demonstration of the nature of the issue.

Note the volume difference when the Far right of the sequencer is actually being used .. it should be at the initial attack point and should not return after the note is lifted .. but it does after the envelope has decayed.

Ace ! Looking forward to this, abusing those sequencers is a key part of the experimental fun

One more UI issue that relates to all plugins, not just the beta :

Bug :
Vox count UI dials mod display not updating ..

The information rendered on the dials is very slick and very very helpful in predicting what impact certain modulations will have

This is especially useful for vox - one of my favourite aspects of this suite of plugins

However, despite the dials being very slick and responsive when the modulation input is wild and complex, the dials to not update when the vox count is changed !

frequently i may be changing vox count and it gets very confusing when various dials still show traces of the previous modulation extents - the only way to correct this is to interact (and change setting) for that dial

I'd like to think there was a way for those dials displaying the spread of vox modulation to be re-displayed correctly as soon as the vox count is changed : ) please

^ Excellent, it's not always easy to know if two users are experiencing the same things, especially when the issue can depend on aspects of the voice state prior to trying ..

Bug :

I'd like to propose this issue as a bug, it's also affecting the 1.02 release and i can't remember if i mentioned before, but as it's still present i thought i'd flag again

With all other Madrona Labs plugins, if you click (momentary on/off) on a patch cord at an inlet it will highlight the start and end nodes, if you want to delete, you actively have to drag away or delete, this is a good system, it lets you trace cabling and does not do anything harmful

With Virta however, if you click (as above) it will immediately bypass highlighting Nodes and goes for deletion X cross, this means you have to be very careful not to delete connections because it's clearly different from the established ux of the other plugins

The former procedure should be common across all three plugins imho : )

Mavericks (plugins/hosts as above)

Here's a demo voice which (for me) shows this issue and one mitigating way to hide it (another is to patch lfo to +ve high feedback ) - This LFO is just dropping the Pitch to circa 1.0 which kills the clicking which only occurs for non 1.0 Pitch

note: issue is more readily trapped when there are more voices, but if you try again, or come via the original trumpet patch once it is clicking it will also click - it has mostly been glitchy for me ( like 9 times from 10)

--- Pasted from clipboard below --- (created in 1.02, but same issue in 1.2b3)

{
"key_voices": 1,
"key_mod": 1,
"key_bend": 0,
"key_unison": 0,
"key_glide": 0,
"audio_level": -12,
"audio_compress": -24,
"audio_lo_cut": 20,
"audio_hi_cut": 200,
"audio_thresh": -48,
"audio_quant": 0,
"lfo_rate": 0.248562,
"lfo_ratio": 1,
"lfo_level": 1,
"lfo_host_sync": 0,
"lfo_shape": "square",
"lfo_rate_p": 0,
"lfo_level_p": 0.040000,
"osc1_pitch": 55,
"osc1_level": 0,
"osc1_formants": 0,
"osc1_peak": 0,
"osc1_shape": 0,
"osc1_noise": 0,
"osc1_type": "classic",
"osc1_p1_p": -1.788139e-07,
"osc1_p2_p": 0,
"osc1_pitch_p": -0.000002,
"osc1_lin_pitch_p": 5,
"osc1_level_p": -0.020000,
"osc2_pitch": 55,
"osc2_level": 0,
"osc2_formants": 0,
"osc2_peak": 0,
"osc2_shape": 0,
"osc2_noise": 0,
"osc2_type": "classic",
"osc2_p1_p": 5.960464e-07,
"osc2_p2_p": 2.384186e-07,
"osc2_pitch_p": -2.384186e-07,
"osc2_lin_pitch_p": 5,
"osc2_level_p": -3.576279e-07,
"env_attack": 0.001000,
"env_decay": 0.010000,
"env_sustain": 0,
"env_release": 0.010000,
"env_level": 0,
"env_xvel": 0,
"env_attack_p": 0,
"env_decay_p": 0,
"env_sustain_p": 0,
"env_release_p": 0,
"formants_mode": "carrier thru",
"formants_pan_mode": "mono",
"formants_quantize": 0,
"formants_carrier_p": 0,
"formants_program_p": 0,
"formants_shift": -0.500000,
"formants_stretch": -2,
"formants_q": 0,
"formants_shift_p": -1.192093e-07,
"formants_stretch_p": -4.768372e-07,
"formants_q_p": 0,
"gate_dry": 0,
"gate_wet": 0,
"gate_level": 0,
"gate_mode": 1,
"gate_decay": 0,
"gate_level_p": 0,
"pitch_delay_input": 1,
"pitch_delay_input_p": 0,
"pitch_delay_lo_cut": 50,
"pitch_delay_lo_cut_p": -9.536743e-07,
"pitch_delay_shift": 1.327928,
"pitch_delay_shift_p": -0.499999,
"pitch_delay_delay": 50,
"pitch_delay_delay_p": -1.000000e-06,
"pitch_delay_ratio": 1,
"pitch_delay_hi_cut": 20000,
"pitch_delay_hi_cut_p": -1.000000e-06,
"pitch_delay_feedback": 0,
"pitch_delay_feedback_p": 0,
"pitch_delay_diffuse": 0,
"pitch_delay_diffuse_p": 0,
"pitch_delay_dry_mix": 0,
"pitch_delay_wet_mix": 1,
"output_aux_gain": 0,
"output_aux_gain_p": 0,
"output_aux_pan": 0,
"output_aux_pan_p": 0,
"output_in_gain": 1,
"output_in_gain_p": 0,
"output_in_pan": 0,
"output_in_pan_p": 0,
"patcher_matrix": {
"type": "signal",
"width": 19,
"height": 35,
"depth": 1,
"data": [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
},
"key_scale": "12-equal",
"preset": "Fuzz trumpet glitch 3",
"maker_name": "Madrona Labs",
"app_name": "Virta",
"app_version": 65538
}

@thetechnobear

Sounds like the one i already posted at the end of august !
(longish post in here (search trumpet) http://madronalabs.com/users/2702 )

i had made a few versions of that patch & distilled the issue down, so it was repeatable with very little connected/enabled .. i only looked at those patches on release of beta3, but i see the clicking is still there but far worse when i try the source patch, like a thumping random geiger-counter : (

Pitch to 1.0 solved it temporarily too !

Some progress, not 100% yet for my installation ..

Firstly, the Vanishing VST (wrt the 1.02 version was recoverable within Live by not merely using the rescan, but it seems to require my deselecting/reselecting the vst folder en-masse)

So I was able to get back to where i was in L9 and M7 w Mavericks

The b2 beta does not offer an AU that Max is happy to load 'no valid au format exists' (or similar) - yet it does load up in Live

I tried an auval -a (if that was even helpful) ?

So is this something that can be ironed out locally here or is it more fundamental (anything i can try to get the AU in Max) ?