Sub 37 mystery patch behaviour (bug?)

[DrJustice]

I'm having a very strange issue with a specific patch on my Sub 37. The patch was saved with arpeggiator sync on. If I switch off the arp sync and switch the arp on and hold down one or more keys, the synth behaves strangely, with these main observations:

• While holding one or more keys down, the panel buttons and knobs become unresponsive, sometimes taking several seconds between changing a control and the effect of it being heard, then a further delay before the LEDs reflect the new setting (for buttons). The programmer section is still responsive though.
• The unresponsiveness extends to the keyboard handler, as in keys responding sluggishly to pressing and releasing (the arp plays for a little while after I let go of all keys).
• The Arpeggiator tempo is erratic, changing tempo by itself or as panel controls are manipulated. It also adds one silent note to the pattern, unless back/forth is on.
• If I record something in the sequencer, the panel can become responsive again, but not always (very hard to diagnose). However, the max arp tempo then becomes very low (EDIT: low arp tempo is due to the arp clock divider being at higher value than anticipated).
• After testing for a while, the synth becomes even stranger, with the arpeggiator ceasing to work, not responding at all to buttons presses, regardless of which patches I recall. This requires a power cycling of the synth to undo.
• Selecting the patch, switching off sync and saving it in a new preset slot with arp sync switched off does not help - I wonder if it behaves even stranger after that.

Edit: I've tried to use the editor, without the Sub 37 connected, to cleanse the patch of the "bad bits", but whatever I try it retains the described behaviour. It looks like something in the patch data is firmly stuck in a bad state.

The behaviour is indicative of the CPU being completely bogged down somehow (interrupts firing constantly, FIFOs filling up uncontrollably - that kind of thing).

The synth runs the latest firmware v 1.2.0. The patch was created from the standard init patch. I've not been able to reproduce the behaviour yet, by making new patches and saving them with arp sync on - only this one patch and its descendants exhibit this behaviour. There is another thread here with an issue that could be related: Arp Rate Knob Working Properly?

Could some of you guys try this patch (attached below) and see what happens?

[mikeh11]

I can confirm that it does act strangely:
- the arp rate led blinks normally, until the Arp On button is pressed and keys are played, then it becomes a short pulse
- sluggish button response
- extra silent note

It's strange that the sequence says the first step is 42 and the last step is 3.
When I correct that in the Editor (first step 1, last step 2), save it, and upload it, then it plays OK.

But even on the "fixed" version, the LFO leds act strange - full on, not blinking their usual rate, an erratic flicker. Changing the LFO speeds does not affect the LFO led non-blinking. Changing the LFO wave-shape brings back the expected behavior of the LFO led blinking at the LFO rate.

Code: Select all

file "RustInPiece mod+prs.syx"
name "RustInPiece mod+prs"  user
arp on=false latch=false bpm=142 gatelen=50% swing=50% ckdiv=1/8. s1rst=false
seq steps 42 3
  mod dst='Off/None' amt=0% only=false
  pos  note  n2 note  n2  vel mod  rest  tie   skip  ratc 2
    1    F2   A7  41 105    0   0                        
    2   F#2  A#7  42 106    0   0                        
 <  3    G2   B7  43 107    0   0                        
    4   G#2   C8  44 108    0   0                        
 

Doctor, doctor! The patient needs you!

[DrJustice]

Thank you very much for the test, analysis and fix, Mike!

That sequencer clean up seemed to do the trick. However, in the state it was in, that patch managed to crash the synth even for other subsequently selected patches, so that it required power cycling. So yes, the patient need some attention in that area, which may be that when the sequencer start is after the end, the patient looses its mind.

Edit: to my knowledge, I never did anything with the sequencer while making the patch, which was started from the init patch and done on the synth itself (no editor involved), so I have no idea how it got into that state. The slow arp max rate I experienced was due to the clock divider being higher than usual, again not sure how that came about.

May I ask what tool you used to get that sysex dump?

[mikeh11]

May I ask what tool you used to get that sysex dump?

My own. It's pretty shabby code, though. It's written in Go, but the code quality is my fault, not that of the language.

The Sub 37 Editor shows the same first/last step situation, though. (which was a relief, actually!)

((maybe this bug will trigger a firmware update that will also fix the missing high/low-note-priority functionality - please?!))

[DrJustice]

I just tested whether it's possible to set the sequence start after the end, and I can't do it with either the editor or the synth. Even so this happened while making the patch attached in the OP. I.e. we're possibly looking at a bug in the firmware, which not only assign strange values to sequencer start and end "by itself", but reacts to it as described in the OP.

@Moog: do you pick this one up here, or do I open a ticket?

[Amos]

Hi guys,

thanks for the excellent forensic work so far... this is all very helpful towards a possible fix. Clearly there is some bad data in the preset, and the Sub 37 is behaving oddly when trying to act on this data... how the preset got into this state is an interesting mystery in itself.

I have opened a ticket for this issue and attached the offending preset and your comments/details on the behavior from this thread.
The Note Priority issue is also being tracked and in line for a fix.

I can't comment yet on the timing of the next update as we are still working out our schedule for various projects, but I will make sure these things don't languish.

Thanks and kind regards,

Amos

[DrJustice]

...
I can't comment yet on the timing of the next update as we are still working out our schedule for various projects, but I will make sure these things don't languish.
...

@Amos, what's it looking like one and a half year later for a firmware update to at least address the bugs that have been reported?