Firmware v0.57
  • pichenettespichenettes

    http://mutable-instruments.net/static/firmware/

    Not a super impressive update, but some of you might find some of the things here useful:

    • The MIDI vs audio priority thing that was introduced in v0.56 can now be disabled (to revert to pre-0.56 behaviour). This is done in the channel selection page. When the channel is prefixed by a ‘+’, the audio is less likely to get glitchy, at the cost of some MIDI data being discarded to keep the audio rolling.
    • A bunch of code optimizations in the audio rendering makes the UI and MIDI a bit more responsive when a supercharged patch is playing.
    • The beginning of the step sequencer pattern can be moved (with the first knob). Visually it looks like the pattern is rotated but this is not moving data, just shifting the start point. Step sequencer start and length parameters are assignable to knobs in the performance page. My favorite game: create a pattern (obviously mapped to pwm1 with oscillator 1 set to vowel), set the length to 7 or 11, and move what’s in the window with the start control.
    • Parameters are addressable by CC. 16-19: oscillator 1. 20-23: oscillator 2. 24-27: mixer. 28-31: filter. 102-105: envelope 1. 106-109: envelope 2. 110-113: LFOs.

  • 11hz Robot11hz Robot

    oh hell yes! this great news! You call this not super impressive? Can’t wait to see what you consider and impressive update.

  • glitchedglitched

    Hey there, great update!
    The shifting seq pattern is worth its weight in virtual gold! Instant variations.

    I think there is a minor problem when using “seq” as the waveform for LFO1 or LFO2.
    Well, not a problem, per se, but a preference.

    Let me just ask: Are the LFO’s “free-running”, even when their rate is a multiplier of the tempo?
    I discovered that my modulations weren’t in sync when “wv1” was set to “seq” and “rt1” is set to “x16”, with a sequencer length of 16 steps. I thought it would act the same as when a “virtual patch cord” source is “seq”.
    In other words, I expected the LFO to “lock” to tempo.

    You can see what I mean if you use the above settings and set a patch cord up this way:
    source: LFO1
    destination: pw1
    amount: 63
    (Use the “vowel” osc or cutoff for most dramatic results.)
    Don’t forget to fill the seq with some random values.
    Use the arp and hold a couple keys.

    Now, set the modulation amount to zero.
    Set up a new “patch cord” with the source as “seq” and destination as “pw1”; the amount should be 63.

    The first example is clearly not in sync, as the change in values is sluggish.

    Is this a bug or does this call for a new feature: LFO’s that reset on a key press?
    If you were to implement such a thing, you could have another set of multiplier settings that indicate that the LFOs reset : r1, r2, r3-r16.

    What are your thoughts, pichenettes?

  • salkinitzorsalkinitzor
    super nice update! will check it out asap!

    as he said: Can’t wait to see what you consider and impressive update. =D
  • rumpelfilterrumpelfilter

    Looks like an impressive update to me!

  • pichenettespichenettes

    @glitched: the LFOs are neither free running nor retriggered at a key press. They are free running as long as there’s no 4 beat interval during which no note is pressed. After that, their phase will be reset to 0. Same thing for the arpeggio pattern. That’s why the tempo LED continues “counting” for a while after you release a key. During the time it continues counting, LFOs/arpeggiator pattern will not be reset if you press a new key. If it stops blinking it means that it’ll reset at the next key press. In other words it tries to reset/trigger only you start playing after a long pause.

    But there might be a problem with the LFO thing – I’ll have a look. Sadly some of these things I very recently added are often “cool hacks”, so they might not fit well together with all the other features that have been there for 6 months.

  • pichenettespichenettes

    For those who haven’t upgraded, please wait, the code optimization introduced a hairy bug…

  • pichenettespichenettes

    Fixed. The problem occurred with the arpeggiator – in some situations it got stuck and no note was played.

  • pichenettespichenettes

    @glitched: I think there’s another factor to explain the difference between LFO with step seq waveform and the step sequencer itself: LFOs are centered. If you program the sequence 0f0f0f0f0f0f0f0f, and modulate the cutoff with the step sequencer and an amount of 63, you will get: cutoff, cutoff + 128, cutoff, cutoff + 128. While if you use the LFO, you will get: cutoff – 63, cutoff + 63, cutoff – 63, cutoff + 63…

  • 11hz Robot11hz Robot

    is the fix getting a new version number or is it a fixed v0.57?

  • pichenettespichenettes

    It’s a fixed v0.57 (the file in http://mutable-instruments.net/static/firmware/ with a 16:15 timestamp is the right one).

    I think this is going to be my last “quickie” upgrade. I will try to do more resting before posting. I’m sorry for those who have upgraded and got the arpeggio bug.

  • glitchedglitched

    Thanks for the explanation, but the main issue is the timing of the LFO when “seq” is the waveform. The change in parameter value always seems to be a little late when used with the internal arp.
    If the phase is reset to 0 after a certain amount of time, shouldn’t the LFO (seq wave) be in perfect sync with the arpeggiator upon the next key press?

    Anyway, it’s not a huge deal, but it sort of limits its use for me, especially when you’d like to do something silly, like: having a half-time sequence controlling the filter for a controlled s&h-style effect, while the “real” sequencer is modulating OSC1+2 at full-speed. I mean, you CAN do this, but it will sound a little sloppy if everything isn’t in sync.

    Again, it’s not a deal-breaker, I just think the sequencer is awesome and if there was a way to use it at different speeds, at the same time, in sync, that would be crazy good.

  • EATYoneEATYone

    ...Same issue with the CC, same prob than the nrpn… playing with a CC during the playback is ok, recording the ccs events is ok too, but playing what u’ve recorded isn’t ok…If u quantitize your automation all is ok ???? Tested under live with M4L, and under Logic with the hyper editor…I’m uploading a video to illustrate: http://www.youtube.com/watch?v=RILJlnkpNE4 (in progress)

  • EATYoneEATYone

    I think i found the solution, i will test it toonight

  • EATYoneEATYone

    Hop my solution will be ok, cause i want to play with that toonight:

  • billygombergbillygomberg
    yeah speedlim/qlim is definitely going to help you if yr having MIDI chokes.

    buy seeing how cleanly you've broken out some essential params - I was wondering if you would mind sharing yr Max code for Shruti controls. I see you've done the work in M4L, I don't use Live but I'm assuming that the Maxing will still work separately.

    Would be very appreciative as I've busted out control codes for a couple of devices and know how tedious that can be. let me know, thanks!
  • EATYoneEATYone

    Sure i Will share it!

  • EATYoneEATYone

    It’s ok!!!!!!!!! Have to finish it now! It’s so good…..

  • billygombergbillygomberg
    ugh how about my "buy" typo. native english speaker w/an education.

    thanks in advance, EATYone.
  • dnigrindnigrin

    I too would love the native Max patch, thanks in advance EATYone!

  • billygombergbillygomberg
    alright can't wait to see some "copy compressed" code start showing up here in addition to all our heady synth/circuit talk
Add a Comment