BETA OS v1.1.5.9 Bug Report Thread

Razmo · « **Reply #20 on:** August 24, 2018, 03:44:18 AM »

Addition to my above post:

I have the LFO in question set to 2 steps per cycle in the program.... that worked fine with prior OS'es... I tried changing this with OS v1.1.4.18, and now it has to be set to 4 steps for the program to work the way it did before... this seems illogical, and i believe you must have accidentally changed the divisions of the LFOs somehow...

I'll add that I'm clocking via the internal master clock, I'm not sync'in to MIDI clock in any way.

Razmo · « **Reply #21 on:** August 24, 2018, 03:56:41 AM »

One more note: OS v1.1.4.18 is making every program I've made that use the LFOs in clocked mode, not sound the way they did before v1.1.4.18. The division settings has been messed up. This must be a bug.

skrohmer · « **Reply #22 on:** August 24, 2018, 11:18:23 PM »

Hi,

I have recently updated to V 1.1.4.13, however did not try several version which came up during the last months. Now I see that the LFO LEDs are flashing in a very strange way. Before I contact the support, can anyone reproduce this? Example:

1. Create Init Patch -> all four LEDs are static on
2. Switch LFO 1 to a different waveform -> LED goes off and stays off
3. Switch LFO 2, 3 or 4 to a different waveform -> LED is flashing quickly
4. Switch all LFOs to waveform Square and activate CLK SYNC for all
5. Select LFO 1 and change FREQUENCY -> LED of LOF 2 is flashing according to the frequency
6. Same happens for LFO 2 and 3 -> LED of LFO 3 and 4 is flashing

Seems to be a wrong assignment, frequency of LFO n affects LED n+1.

eagleman · « **Reply #23 on:** August 25, 2018, 05:17:15 AM »

I can verify your example. It's the same with the resent 1.1.4.18 update.

skrohmer · « **Reply #24 on:** August 25, 2018, 05:24:20 AM »

Thanks, support has been informed.

Razmo · « **Reply #25 on:** August 26, 2018, 01:00:39 AM »

Yup... I have the same response... most certainly a bug there. Seems like the LFO's are a bit buggy... latest beta also introduced problems with the division settings.

Razmo · « **Reply #26 on:** August 26, 2018, 03:00:07 AM »

I've written about this bug in the Bug thread, and I've also written support about it... but I'd like to hear if anyone else has noticed, that any program they have created, or other preset that use clocked LFO's sounds different with the latest 1.1.4.18 OS?

All the presets I've made thus far, that use the LFOs in clocked mode (as master or slave, it does not matter), seems to have the division settings messed up... one particular program i made, that had it set to "2 steps", now sound completely wrong, and is fixed now setting it to "4 steps" instead.

It happens to ALL programs I've made, that use the LFOs in clocked mode.

I really hope that DSI will be fast with fixing this bug because it temporarily stops you from wanting to create new presets until it's fixed... otherwise anything you create that use the LFO's in synced mode will sound wrong when they have fixed it...

http://razmo.ziphoid.com/Bug.mp3

The above audio demo show what I'm talking about. The first sound you hear is a single key being pressed and held for the duration of the sound... that first sound has the Time Division setting of LFO1 set to 4 steps... This is the way the sound was made to sound, but to make it sound like this after OS 1.1.4.18, I had to change the Time Division setting of LFO1 to "4 steps"... in my original preset it was "2 Steps"... with OS 1.1.4.18, and the Time Division set to "2 Steps", it now sounds like the second sound in the demo above... clearly different because the Time Divisions of 1.1.4.18 does not match prior OS'es anymore.

A bit about the sound:

the two oscillators are playing different pitches that are set up by the gated sequencers... seq1 play oscillator 1, and seq2 play oscillator 2... they gradually change the pitch upward with oscillator 1 playing the first note, oscillator 2 playing the second, then oscillator 1 playing the third and so on... the sequencers restart on every new note played so that the sequence start over.

With this alone, the two oscillators would just mix equally, and the pitch changes would be abrubt as the sequencers change the pitches, so to get those smooth fades you hear in the first sound, I use LFO1 set to a triangle, and let this LFO smoothly change the oscillator MIX parameter... that way, when one oscillator is heard only, the others pitch is changed by the sequencer for that oscillator... but for this to work, the LFO would have to be both keysync'ed and clock synced, otherwise the LFO will not line up with the sequencers. The LFO and sequencers play VERY tight together in this sound, so the Time Division setting of LFO1 is crucial to avoid that the oscillators are heard when their pitch is changed by the sequencers.

The second sound you hear has very abrupt changes because the LFO is no longer correctly synced with the pitch changes in the sequencers...

I have made 3-4 other programs that use a clocked LFO, and these also sound wrong with OS 1.1.4.18...

AlainHubert · « **Reply #27 on:** August 26, 2018, 07:05:33 PM »

Just updated to 1.1.4.18 and there's a bug with the LFO speed LED indicators section. When selecting LFO1 and trying to adjust its speed the LED of LFO2 changes speed instead (although the speed of LFO1 actually changes as it should). Same thing for LFO2, when trying to change its speed with the Frequency knob, the flashing speed of LFO3 LED changes instead of the one for LFO2. Not to mention the microscopic font of the OLED display during firmware update...

Not that those LEDs are terribly useful in the first place (can hardly see them flashing anyway), but it's still an additional bug that wasn't there before.

There's been a new firmware update for the OB6 too, and it also messed up some of the LEDs on the front panel (support already advised of it, awaiting conformation from them).
I reverted back to a previous firmware version on the OB6.

And I think I'll have to do the same on my REV2 (going all the way back to 1.1.4.5 since it's the last one that didn't add any new bugs and was stable).

That firmware code must be a real mangled spaghetti mess if LED indicators aren't pointing to the right variable in the table after new code is added... ?

What the use of adding new features and correcting bugs, if it means creating new and unrelated ones each time ?

BTW, DSI programmers should port the digital encoder software fix from the Prophet X and REV2 to the OB6 also. At least that worked well without messing up something else. Because who needs acceleration on an encoder with only from 3 to 10 possible positions ?

RonGerrist · « **Reply #28 on:** August 27, 2018, 08:25:00 AM »

To me, as a software development team lead, this bug fixing and adding features look very unprofessional.
How 1 fix creates a new bug in a totally unrelated area is beyond me. Also, don't they do basic regression testing?

I'm not updating my REV2. I'm happy it works fine now.

I wonder when there will be a REV2²

extempo · « **Reply #29 on:** August 27, 2018, 10:28:39 AM »

Thanks for your bug reports, everyone. I'd just like to take a moment to remind everyone that these are BETA OS versions we post here, and not production releases. No one is under any obligation to load these versions, of course. If you've reported a bug directly to support, you will hear back from someone, either with an acknowledgment of the bug or a request for more information or additional steps for reproducing it. Sometimes fixing existing bugs or adding features changes other things in unexpected ways. Thanks!

RonGerrist · « **Reply #30 on:** August 27, 2018, 12:13:18 PM »

Quote from: extempo on August 27, 2018, 10:28:39 AM

Thanks for your bug reports, everyone. I'd just like to take a moment to remind everyone that these are BETA OS versions we post here, and not productions releases. No one is under any obligation to load these versions, of course. If you've reported a bug directly to support, you will hear back from someone, either with an acknowledgment of the bug or a request for more information or additional steps for reproducing it. Sometimes fixing existing bugs or adding features changes other things in unexpected ways. Thanks!

You have a fair point, my apologies if I came across a bit too harsh.

ffx · « **Reply #31 on:** September 07, 2018, 04:01:24 AM »

Hi,

I have two questions regarding beta firmwares:

- Can I easily downgrade to my current stable version 1.1.4.5, if the beta version is not satisfying, or is that a problem?

- Do I still have to do those global parameter resets and OSC calibration?

Thanks!

Kasimir Effekt · « **Reply #32 on:** September 07, 2018, 12:44:38 PM »

I'm not sure if this is a bug, but maybe someone of you could try to see if this behavior also appears on your device and if that is intentional:

Load a basic patch, reduce cutoff and set a high filter env amount with short decay (naturally, you get a "clicky" sound).
If all 16 (or 8 ) voices are played while the sustain pedal is held down, the envelope will no longer be triggered, until you deactivate sustain! Every added note now sounds very dull...
Oddly enough, you can fix this behavior by setting Keymode to "retrigger" - which according to the manual should only affect unison sound ...

Actually, from the experience with other polyphonic synthesizers, I assume that with the consumption of all voices, "voice stealing" should occur - but the retrigger behavior should not change!

Or am I wrong, and that is normal behavior? Thank you in advance!

dequalsrxt · « **Reply #33 on:** September 18, 2018, 10:32:05 AM »

Don't know if this is a bug or user error - don't *think* it's user error, could be wrong though, just can't figure what it might be. Anyways, I updated my Rev2 desktop to 1.1.14.18 yesterday to try out the poly sequencer MIDI out. It works, but I'm not getting any note off information, all the notes just hang there. I've got a workaround, I have my DAW (Bitwig) set up to force all incoming notes to a fixed length (I'm using 16th notes) and then everything works fine. So it's not freezing up, it's continues to send the correct note information. There's no MIDI incoming to the Rev2, just MIDI out from the Rev2 to my DAW. edit: I'm using DIN, not USB for MIDI. I'm clocking the sequencer with gates/triggers.

maxter · « **Reply #34 on:** September 18, 2018, 11:35:23 AM »

Quote from: Kasimir Effekt on September 07, 2018, 12:44:38 PM

I'm not sure if this is a bug, but maybe someone of you could try to see if this behavior also appears on your device and if that is intentional:

Load a basic patch, reduce cutoff and set a high filter env amount with short decay (naturally, you get a "clicky" sound).
If all 16 (or 8 ) voices are played while the sustain pedal is held down, the envelope will no longer be triggered, until you deactivate sustain! Every added note now sounds very dull...
Oddly enough, you can fix this behavior by setting Keymode to "retrigger" - which according to the manual should only affect unison sound ...

Actually, from the experience with other polyphonic synthesizers, I assume that with the consumption of all voices, "voice stealing" should occur - but the retrigger behavior should not change!

Or am I wrong, and that is normal behavior? Thank you in advance!

I think it's normal behavior. It's mainly for unison/mono mode, where each voice is already assigned, meaning the voices don't cycle. The trigger mode should, imo, set how the envelopes of the voices act when a voice is "stolen", or reassigned a new note, when the envelope has not completed its last cycle. I use OS 1.1.4.5, and it's the same there so I think it's intentional.

minor7th · « **Reply #35 on:** September 19, 2018, 11:35:55 AM »

I just updated my Rev2 16Voice to 1.1.4.18 and I came across a bug while using the sustain pedal. Playing one note with key down -> sustain pedal down -> key up sustains the note as long as the sustain pedal is held down. This is the expected result, so far so good.
This only works for the first 8 consecutively played notes, for the next 8 notes there is no held sustain while the next 8 notes do work as expected again. It seems to me, that the sustain works only for one sound board. Is this a general bug or a malfuction of my synth?

minor7th · « **Reply #36 on:** September 19, 2018, 12:01:59 PM »

After investigating the above bug some more I can conclude, that at least my instrument behaves strangely. I can reproduce the following behaviour consistently.

Playing a program in "single mode" (meaning neither stack nor split is activated) after 8 played notes there is no sustain function for the next 8 consecutively played keys only to have sustain again for the next 8 notes. If I play two keys at the same time, the sustain function alters after 4 played double note chords. The same is true for playing the same program with "Edit Layer B2 activated.

Strangely enough, playing still the same program but with "Stack A+B" activated, no matter how many notes or chords I play, the sustain functions for each an ever one and for both layers as is expected.
With the same program in Split Mode I get consistend sustain function on the lower keyboard while no sustain on the upper part, which I guess is as designed.

dequalsrxt · « **Reply #37 on:** September 20, 2018, 01:52:51 PM »

Ok I don't think this behavior is actually bug. It occurred to me last night that I'm not getting note off information because I'm clocking the sequencer with gates, so there is no midi timing info for the rev2 to pass on, just pitch.

Quote from: dequalsrxt on September 18, 2018, 10:32:05 AM

Don't know if this is a bug or user error - don't *think* it's user error, could be wrong though, just can't figure what it might be. Anyways, I updated my Rev2 desktop to 1.1.14.18 yesterday to try out the poly sequencer MIDI out. It works, but I'm not getting any note off information, all the notes just hang there. I've got a workaround, I have my DAW (Bitwig) set up to force all incoming notes to a fixed length (I'm using 16th notes) and then everything works fine. So it's not freezing up, it's continues to send the correct note information. There's no MIDI incoming to the Rev2, just MIDI out from the Rev2 to my DAW. edit: I'm using DIN, not USB for MIDI. I'm clocking the sequencer with gates/triggers.

minor7th · « **Reply #38 on:** September 23, 2018, 12:30:16 AM »

Fixed with newest OS 1.1.4.25

Quote from: minor7th on September 19, 2018, 12:01:59 PM

After investigating the above bug some more I can conclude, that at least my instrument behaves strangely. I can reproduce the following behaviour consistently.

Playing a program in "single mode" (meaning neither stack nor split is activated) after 8 played notes there is no sustain function for the next 8 consecutively played keys only to have sustain again for the next 8 notes. If I play two keys at the same time, the sustain function alters after 4 played double note chords. The same is true for playing the same program with "Edit Layer B2 activated.

Strangely enough, playing still the same program but with "Stack A+B" activated, no matter how many notes or chords I play, the sustain functions for each an ever one and for both layers as is expected.
With the same program in Split Mode I get consistend sustain function on the lower keyboard while no sustain on the upper part, which I guess is as designed.

AlainHubert · « **Reply #39 on:** September 23, 2018, 07:50:19 PM »

Thank you DSI for this latest firmware update (1.1.4.25). We can now have a global LFO that remains in sync, or have independent ones by using Key Sync. To put them back all in sync (global), simply using Unison with 16 voices and using Key Sync once to reset them. Except for the random waveform which still behaves as 16 independent LFOs, generating different random values but in sync, unfortunately.

I'd sure would have preferred a dedicated LFO Global Mode (on/off) parameter, but this is better than nothing, and at least now they all remain properly timed and not drifting anymore.

Now, if only that 12 db filter mode would have more resonance, that would be the icing on the cake, but I fear that this is a hardware limitation not fixable in software... Oh well.

There still remains the Tempo LED bug when the REV2 is in Slave Clock mode, with an external MIDI clock source, which flashes twice as fast as the source clock, sometimes not at all, or sometimes stays lit when switching from Master to Slave...