Digitone / Digitone Keys 1.30A : bug reports

[LyingDalai]

Firmware 1.30 is now released.
Discuss here

Remember to back up before upgrading and even load a new empty project to avoid any damage to your current project.
And avoid upgrading before a gig.

---

You encountered something wrong in this OS and want to check if others can replicate it ?
Here is the place.

Doesn’t replace a support ticket, of course, but you might want to check if it’s not a feature before declaring a bug

Please report all bugs via the Support Tickets section on elektron.se if they have not already been confirmed below.

---

[d4ydream]

I’ll kick things off with the first thing I tried; Class compliant audio interface.

Setup: Digitone OS 1.30
USB Settings: USB/Audio
Audio Settings in AUM/Audiobus: 48KHz/256 frames buffer size.

Connected directly to 2018 iPad Pro 11" using a USB Type-C to USB Type-A adapter. iPad OS 13.5.1

Scenario: Hosting one AUv3 synth in AUM or Audiobus. Synth has hold on keys to produce a constant drone.

Issue: Audio randomly stops streaming to Digitone even though the meters clearly show audio coming out of the AUv3 synth. Killing and restarting AUM/Audiobus reconnects the audio. When the audio stops, it does not play over the iPad speakers suggesting the driver crashed or a cable was bumped to break the connection. There is simply no audio. The issue seems to happen when I just let the drone do its thing and don’t interact with the iPad. As though some sort of keepalive is missing.

While both AUM and Audiobus have a means to keep the screen active and audio in the background, I have tried disabling screen lock and Do Not Disturb to no effect. The behavior happens at random but it happens without fail and within 10 minutes or less. Usually within 5 minutes.

This same behavior does not occur with a 2nd Gen. Scarlett 2i4. I have not tested with the Analog Heat MKII.

If others can replicate this behavior then perhaps there is an issue. I can’t prove out iPad OS as the culprit but it does not happen with at least one other class compliant interface.

Update 1: Performed a second round of tests.

Scenario: Hosting Tal-U-No-LX v2 in AUM. Sequenced from Digitone.

Results: Audio stopped at 10m15s. Recovered audio by unplugging and replugging USB cable from the back of the Digitone. Audio then stopped again at 3m43s

Update 2: Audio can be restored by restarting the host app, unplugging and replugging the USB cable, or by changing Settings => System => USB Config from USB Audio/MIDI to USB MIDI and back. With the exception of restarting the host app, the latter two methods don’t require that the synth be stopped and started again. It will still produce levels on the meters and restart audio once connected again.

Update 3: Tested with powered USB hub. Same results. Audio stream stops within 10 minutes or less.

[astricii]

Can you time drop outs with a drone vs something like using the Digitone midi tracks as a sequencer for an app? That should help test the keep alive hypothesis

[d4ydream]

@astricii

Can you time drop outs with a drone vs something like using the Digitone midi tracks as a sequencer for an app?

Going to give that a shot this morning. I did try to time the first tests but the timing seemed random. It was consistent in its behavior though. I’ll post back with results. I wish there were some type of debug mode on the iPad to help with information gathering.

[MikeWestSE]

It happens on my 2015 iPad Pro on GarageBand as well. At first I thought it was the CCK glitching/loosening but it seems random, and like you said the speakers don’t take over and it works again on an app restart. It also appears most likely to happen when I audition a mix without changing anything. You can even reset the connection without restarting the app by resetting the “Run in background” option in GB’s settings (on to off or vice versa doesn’t seem to matter).

I had another experience where the microtiming cursor jumped errantly in the wrong direction whenever I pressed an arrow key, but I haven’t been able to replicate it.

[grubi]

The bug that was driving me crazy and I already reported a year ago is still there: Red triggers turning into yellow triggless locks.

Create a new pattern, e.g. 1 bar long. Place a trigger on any step within the pattern, e.g. on step 5. Now start live recording (press record+play). Play (and record) a note before the existing trigger, and hold it until the existing trigger has passed, e.g. play a note from trigger 2 until trigger 7.

Result: The new note gets recorded, and the existing note turns to yellow, not triggering any more - even if these are two different notes/pitches.

Exception: It works as expected when the recorded note starts at the step immediately before the existing note, i.e. step 4 if the above example. In this case you end up with two red triggers on step 4 and 5, as expected.

I like to add notes in live recording to existing patterns, but this makes live recording useless for me, because I’m loosing already recorded notes all the time. Very frustrating.

FR off-topic : Moderator Edit

Another thought: Still no Arp for MIDI tracks. That’s the most important feature I’m waiting for personally.

[avantronica]

@grubi

I already reported a year ago

what did Elektron say ?

This was discussed during testing and afaik it’s a known behaviour but I’m unsure whether it’s considered a bug - you can step record the arrangement you describe, but often realtime rec (in overdub) it’s desirable to retake, rather than to layer

so I am curious about what they said - it was only discussed in the context of soundlocks recording

@grubi

It works as expected when the recorded note starts at the step immediately before

I see this - it confuses the matter and may point to a conscious choice or an inconsistency ?!

@grubi

Another thought: Still no Arp for MIDI tracks. That’s the most important feature I’m waiting for personally.

this is for bug reports only - we can’t have Feature Requests muddying the topic if there are replies to this

[yghartsyrt]

My DN crashes and needs to be restarted, when I use a MIDI-LFO in Ableton Live to control a parameter on the DN (reverb decay in my case). Nothing fancy going on. Just one arpeggiated track. Tried CC over MIDI and over USB.

The error code is DN0042. (I already submitted a ticket to elektron)

Controlling the same parameter internally in Ableton Live (with DN running as a PlugIn) does not result in a crash

Anyone can reproduce this?

[d4ydream]

There’s been a bug report thread setup here.

[d4ydream]

I’ll update my main post with the test performed but I did setup a synth to be sequenced from the DN. Issue remains.

[yghartsyrt]

As referenced here: (Edit : Merged by Moderator to correct thread)
https://www.elektronauts.com/t/digitone-os-1-30-bug-reports/133255/21?u=avantronica
External MIDI-CC via MIDI or USB crashes DN after a few minutes.

[PekeDorty]

It is a bug in my eyes because nobody has ever brought up a reason why this behavior would be useful.

[d4ydream]

My first thoughts were that the trig is being recorded over with some type of modulation data. I rarely record trigs in live recording mode but I have seen yellow trigs when holding down a key. It is quite possible that whatever is being recorded on a yellow trig happens to overwrite other trigs on subsequent passes.

I “think” that if something like aftertouch or modwheel is mapped to say, filter cutoff, then the resulting change to the filter cutoff is recorded as a trigless lock. I know that aftertouch and pitchbend are not recorded but perhaps their modulated destinations are and it’s just overwritting trigs/trigless locks with new ones.

Intended? Possibly. I don’t think that live recording overdubs in the sense that if a second event occurs on an already programmed trig it will combine the two.

Desireable? Well, if this is the behavior as outlined above it would mean that you probably shouldn’t be holding keys long enough for the sequencer to wrap and start overwriting things.

Just a thought.

[grubi]

@avantronica

what did Elektron say ?

This was discussed during testing and afaik it’s a known behaviour but I’m unsure whether it’s considered a bug - you can step record the arrangement you describe, but often realtime rec (in overdub) it’s desirable to retake, rather than to layer

so I am curious about what they said - it was only discussed in the context of soundlocks recording

I never heard back from them. But I recognized from the forum that many others have reported the same behavior, so I thought elektron must be aware of the issue and did not check back.

[grubi]

@d4ydream

My first thoughts were that the trig is being recorded over with some type of modulation data.

That might make sense if you are recording the same note over an existing note. But it even occurs when you record a different note. I still don’t see the logic behind the behavior. I mean, it’s quite common on grooveboxes and step sequencers to build up a pattern while it’s running. So I think we should be able to add to the existing pattern rather than overwriting what’s already there.

[PekeDorty]

They just need to remove some code … not even adding. In theory this should be not much work.

[astricii]

Interesting. someone in the main 1.2/1.3 post said they were able to fix this with a powered usb hub to usb-c. Hmm.

[avantronica]

@yghartsyrt

External MIDI-CC via MIDI or USB crashes DN after a few minutes.

This has to do with Ableton sending out waaay to much midi data via the LFOs - try to find an LFO that thins the data out - it would be easy to fix in a M4L object e.g.

[avantronica]

@PekeDorty

because nobody has ever brought up a reason why this behavior would be useful.

i just did - to me it seems intuitive also to be able to replace in overdub - ymmv - but this is something you learn to work with on devices without Poly and layering doesn’t always appeal - so it may be the preferred vibe for some folk - in any case, the only meaningful response to this is an official one if people actually submit a support ticket - that’s the only reply which will dictate what happens next - it’s not an unknown behaviour, but whether it is considered a clear bug isn’t clear to me - that’s why i would like to hear the feedback too

[jazznbass]

@avantronica

This has to do with Ableton sending out waaay to much midi data via the LFOs - try to find an LFO that thins the data out - it would be easy to fix in a M4L object e.g.

if this is a possible reason then a slow speed square LFO (or sample and hold) should not overflow midi data buffer.