The Official DSI/Sequential Forum

Switching edit layers messes up P12 delays, lfos (when slaved) SOLVED

Hi All. I'm running up against an issue that is driving me crazy, and I'd really like to know how you all get around it.  In a nutshell, when slaving the P12 to an external source, hitting the layer select button when choosing a layer to edit will throw off any synced delays or lfos, setting them to a new value that is not the same as the value shown on the P12 display.  The incorrect value(s) are audible, and will not resolve until the external clock is stopped and restarted.  The easiest way to hear this is when using multimode, as the bug will occur 100% of the time when slaving to external clock. It will also occur when not in multimode, but in multimode isn't as frequent and seems almost random in nature. It will never occur if the P12 is the clock master.

Here's what I don't understand: I have worked closely with DSI support and they have told me they have documented the behavior I'm describing, but have stopped short of calling it a bug. They won't confirm that they will work on a fix, either.  I can't for the life of me figure out why an issue that renders the P12 unpredictable or even dangerous in a live setting, when the user is doing something as fundamental as selecting one of the two layers to be controlled by the front panel knobs, is such low priority for DSI.

Add to that that I can only find a single user complaint about this same issue online, and I feel like I'm going crazy.  Am I really the only person who wants to clock the P12 from an external source, while sending it sequences, and selecting layer A or B to modify the sound in real time?

How do you work around this, and/or justify this (IMO) huge oversight?  I love this synth, but it is painful to have spent so much money on it, yet can't safely modify sounds live.  If anyone wants to test, I can give you exact reproduction steps... Thanks.
« Last Edit: December 14, 2017, 04:14:43 PM by extempo »

I have the P12 module. 100% sync it externally and 99% of the time use two layers. Controlling them on 2 different channels. Sending clock on both channels. I have not seen this behavior.

Joosep (or anyone else) - Would you be willing to run a short test and tell me your results?  Here are the steps:

Make sure the P12 is slaving to ext clock.
Make sure the P12 is in multimode.

1) Initialize a basic patch.
2) Program a short sound on layer A, and set up a delay with a relatively high volume and feedback level - not extreme, but enough to hear how the delayed signal sounds across an entire bar.
3) Sync the delay. Set the delay time to any value that repeats a number of times through one bar.
4) Send the P12 a clock signal and a single midi note at the start of a one bar loop. Take note of the timing of the delayed signal; how it sounds within the bar.
5) Do not stop the clock. Hit the A/B layer select button twice - basically you are just flipping from A to B and back to A
6) Listen to layer A again: Notice how the audible delay has changed to a new value, even though the display still indicates what you set earlier.
7) Stop and restart the clock: Notice how the delay resumes the correct originally programmed periodicity.

It may be helpful to run a click or metronome while conducting the test, to better hear how the delay time changes.

Joosep (or anyone else) - Would you be willing to run a short test and tell me your results?  Here are the steps:

Make sure the P12 is slaving to ext clock.
Make sure the P12 is in multimode.

1) Initialize a basic patch.
2) Program a short sound on layer A, and set up a delay with a relatively high volume and feedback level - not extreme, but enough to hear how the delayed signal sounds across an entire bar.
3) Sync the delay. Set the delay time to any value that repeats a number of times through one bar.
4) Send the P12 a clock signal and a single midi note at the start of a one bar loop. Take note of the timing of the delayed signal; how it sounds within the bar.
5) Do not stop the clock. Hit the A/B layer select button twice - basically you are just flipping from A to B and back to A
6) Listen to layer A again: Notice how the audible delay has changed to a new value, even though the display still indicates what you set earlier.
7) Stop and restart the clock: Notice how the delay resumes the correct originally programmed periodicity.

It may be helpful to run a click or metronome while conducting the test, to better hear how the delay time changes.

Sorry it took so long.

Did exactly that and noticed no changes with the delay. Everything works as expected on my P12 module.

Joosep - thanks for testing. I don't know what to make of this; a couple days ago I got a PM from another user who confirmed the bug as i described it, with their own P12 module. Obviously this issue can't get traction unless it can be reproduced always, and the differing results are troubling. What firmware do you have on your Prophet? And you're positive you had it set to multimode, and used a beat-synced delay? Thanks again.

Joosep - thanks for testing. I don't know what to make of this; a couple days ago I got a PM from another user who confirmed the bug as i described it, with their own P12 module. Obviously this issue can't get traction unless it can be reproduced always, and the differing results are troubling. What firmware do you have on your Prophet? And you're positive you had it set to multimode, and used a beat-synced delay? Thanks again.

Im running the BETA Main OS v1.4.2.3, the latest as it stands today.
And yes, multimode was turned on, as that is how I only use my P12M.
I have it hooked up to a sequencer and control it entirely from it. Most of the patches I make have the LFOs and/or the delays synced to the tempo coming from my sequencer and all of my project use the P12M in multimode and I have never witnessed this bug. But maybe I am doing something wrong... :)

Joosep - What are you using as the source of your external clock? The other user who I talked to who has the bug too, uses an e-rm multiclock. I also use the multiclock. I'm not sure how the multiclock would be able to mess up the P12 during layer changes, but right now its the only common denominator.

Joosep - What are you using as the source of your external clock? The other user who I talked to who has the bug too, uses an e-rm multiclock. I also use the multiclock. I'm not sure how the multiclock would be able to mess up the P12 during layer changes, but right now its the only common denominator.
I have a sequencer pushing out clock on all channels. All of my instruments are connected to a iCM4+ that handles all my MIDI operation.

Just wanted to let anyone know who views this thread that my issue is SOLVED (sort of). I say sort of because I cannot pinpoint why the issue was solved, but only the how.  To the point: I invested in a RME Fireface UFX to replace the iConnectAudio4+ I had been using previously. As soon as I got the Fireface connected and the P12 routed, I conducted the above test again. My midi routing remained the same as before the Fireface; all midi being handled by an E-RM Multiclock.  Result -zero issues whatsoever.  I have no idea why changing my audio interface would fix this, but there you have it. :-\ :D  My apologies to giving DSI a hard time. I now understand that the bug isn't happening on all setup combinations, so of course they might not have been aware of it and definitely wouldn't be throwing development resources at it. Although I prefer full solutions, I'm unlikely to be using the iCA4+ again, so I'm just happy that my Prophet is performance-stable now.
« Last Edit: December 14, 2017, 03:53:03 PM by Zac Kyoti »