Workflow customization discussion

[Pym]

I'm writing this as a general response to a general set of problems we run into on a daily basis. To start, this is an outline of a design exercise where a user has asked for a very particular workflow change due to an annoyance in the synth's workflow compared to his ideal workflow. This is a very common response and what drives progress. This particular annoyance is very context dependent and not a particularly global (see what I did there?) annoyance. The workflow is basically:

1. Start up the Pro3
2. Current: Load last program saved with globals -> Desired change: Select the program X I want to edit on startup
3. Start playing with synth

This user's particular criteria is that the program X he wants to change on startup is often the same, and so he wants to have editable control on loading that program.

To get there, and determine whether or not it's a reasonable feature change, we need to break down the current way it works into byte sized chunks, each representing a design choice and constraints that we need to take into consideration... hopefully this will be fun to follow:

The current way the design works is that we load the last program you had loaded when you save globals

One of the design constraints is how do you save and recall that program? To recall, you load from flash memory, to save, you write to flash memory. Flash memory has several characteristics that come into play here... writes are SLOW and writes are LIMITED because the more you write, the more likely it is something in the memory will break.

Because memory writes are slow, we can't easily save to flash in realtime while the synth is making sound. There is a lot of waiting to do. We have solved that problem to some degree, but only recently, so one constraint is that we can't really do this in realtime. The sound will stop as we save the program to flash.

The other problem is if we save every time you write a program, it adds up fast in terms of the flash memory writes before probable failure, so if at all possible we don't want to write every time you change presets

Of course we can address either of those, but they would take a lot of time or money because there aren't easy options. So now let's figure out if it's worth putting our resources into solving this and what it gives us... the first thing we'd likely do is determine if this is our current solution is optimal and whether there are advantages to leaving it the way it is

In this case there are several. The most obvious is people are used to this workflow. Double tapping the 'global' button is extremely quick and something you can map to your muscle memory. It forces the user to consciously set the program, which fits with our flash memory constraint of slow writes, and also limits the amount of writes by making it user triggered vs. automatic. Compare this to a far more time consuming task of going to a specific global to select the program/bank you want to load... this is a good comparison because it is actually one of the possible solutions for the annoyance this user has. If you could set (or override) the way the default program is loaded, this particular user's workflow would be improved

But let's consider a DIFFERENT enhancement... other users have a different workflow. Some users want it to always recall the LAST LOADED preset which is a far more common request. If we did that automatically, we'd have to spend time figuring out how to minimize flash writes and do it in a transparent way. The advantage would be completely removing #2 from the workflow in a transparent way. A lot of users would love that, but it would require a lot of resources and man hours we could put into other problems. In this case, it's not mutually exclusive with our original goal. In fact, if this was implemented, it would be easy to add a global to allow some users to recall a specific program/bank every time if they wanted to override the behavior. Best of both worlds! So now we have a goal.

So the next question is, if we add something, does it take away from EXISTING workflows... because that is actually a far more important problem and why things change slowly. Once you have established a way of doing things and trained yourself to do them quickly, you don't want to have to learn a different way. It slows you down and forces you to train a new system.

For the users that want to load the last loaded preset, you need to leave the global method of double tapping, or automate it so the user doesn't need to learn a more complicated procedure.


I'm going to leave my explanation there to invite discussion. I've already thought of several ways to balance these variables and a very compelling global solution to these general sorts of problems I'm mocking up, which I will probably expand on if this discussion produces interesting results

What I'm curious and asking from everyone to add to this thread, is their own workflow annoyances broken down:

• What is the current workflow?
• What part of it do you want to change?
• How does that impact people who are used to the current workflow?
• In what contexts is this an improvement to efficiency?
• In what contexts does this make things more complicated?

And if we come to some good conclusions, I'll see what I can do to provide a developer/designer perspective on the challenges to implement, and who knows might even get some community sourced ideas into the synths to make everybody happier!

[guyaguy]

• What is the current workflow? Not clicking Global because I'm lazy
• What part of it do you want to change? Ideally the last patch would load in case of a brown out, someone tripping over cables, etc, but also just to pick up whatever I was working on before
• How does that impact people who are used to the current workflow? I don't know but I suppose there could be a setting for which behavior is preferred.
• In what contexts is this an improvement to efficiency? It's a minor efficiency gain
• In what contexts does this make things more complicated? My guess is that few people are clicking Global before each power down so I doubt it makes things more complicated but maybe other uses will have different feedback.

Regardless of the solution decided on, this is a minor issue for me.

[Gino.Cortesi]

What is the current workflow? Typically I start a new project on my Digitakt, and send a program change to the Pro 3. I also (about 20% of the time) start the Pro3 by itself with headphones to continue to work on that program. I will admit that I typically forget to do the "tap global twice" trick, and just load the program I want manually. 

What part of it do you want to change? I don't have a strong opinion on this, but the way it works now seems like a quirk vs something people would want to see in other synths. I just assumed this is how DSI/Sequential synths work because the Pro3 is the first Sequential synth I've owned. For me personally, I'd prefer if it loaded the last program so it's as I left it.

How does that impact people who are used to the current workflow? I bet most people are not confident how it recalls the last program as pressing global twice isn't intuitive IMO.
 
In what contexts is this an improvement to efficiency? For how I work, it doesn't effect me very often. I set the program from another device most of the time.

In what contexts does this make things more complicated? I think it's more complicated to think "ok I need to turn off the midi clock, hmmm before I do that I know this will set the default program, is the one I have loaded the one I want?" I'd prefer if going into global settings didn't set the default patch automatically. 

Overall, this is a very minor issue for me. I'm fine with how it is, and can accept it. I would vote that dev resources are spent on things that add synthesis capabilities Still I understand how sometimes a little thing can be an annoyance for some (and maybe on both points of view), and I appreciate the thought you're putting into this. If it MUST be fixed for the good of sanity, and peaceful rest, then I'd say make it recall the last program.

I don't know the architecture here, but is there a way to only remember the ID for the currently loaded program, so that it doesn't need to write much info?

Best regards,

Gino

[Fiddlestickz]

I don't always want the last patch I worked as the patch I open up, surely others want this same feature too..? I work on many patches and the one I started with might be the one I want to start with tomorrow or next day but it might not be the last patch I'm using when I turn synth off, do you see the problem here, i now have to go looking for the one I want and load and then press global twice..

my biggest gripe is not being able to see patch name after I've made one single edit, and can no longer get it back unless I reload it. It should be that I edit something and it returns to patch name, over and over and over or some button to return to patch name.

[Pym]

Please note I was using the example just as an example. Feel free to add ANY annoyance or workflow optimization you might like to see here for discussion

[MKDVB]

tl;dr - I think what I'm trying to say is that maybe there's a way to focus on enhancements/features that allow end users to create their own workflow with the instrument vs features that force a workflow on users.

I think your posts raise a lot of interesting questions & perspectives. I'm sure I haven't thought about the UX & workflow angle as much as you so I'll just offer the view from my end.

First off, I think it's vital to acknowledge that Sequential synths don't exist in a vacuum -- they exist in a marketplace & users use them in the context of a studio or rig, etc, with gear from multiple manufacturers. I'm personally not vested in the double-tapping global / preset debate. It would be nice if it defaulted to last preset or had a global setting option but
 if the market has fairly established conventions, then bucking those conventions is not simply a minor inconvenience to the end user ... it can be quite a burden actually if they're not intuitive & even if they sound as minor as double-tapping global.

I have "only" 5 synths ATM but it's not like I can play each one every day to develop & retain muscle memory  -- that would require a very conscious effort, which I would rather devote to making music.  A company like Elektron asks/requires its users to invest to develop that muscle memory but in exchange, they open up creative possibilities.

It's weird because I've churned through a lot of gear & the Sequential synths are the ones that most resonate with me, they feel the most like "real" instruments & I love playing them but I haven't kept any of them until now. Some part of it is that they're workflow stoppers.  There are some minor design choices that force users to do it the Sequential way or else. For instance, I had high hopes that the Pro 3 could be my studio hub but it just doesn't go all the way in terms of sequencer/external capabilities.

Like I literally bought my first Chase Bliss pedals with this grand plan that I'd sequence & control them from the Pro 3 sequencer but didn't do my homework & discovered that the Pro 3 only allows a limited # of MIDI CC's in the sequencer.  I'm assuming there's a good reason for this limitation but it's the first MIDI sequencer that's had this issue (various Elektrons, Deluge, Pyramid) so I never thought to check before.

One of my biggest peeves is no real-time record in the sequencer, which basically means the Pro 3 can never truly be the hub of my studio (among other reasons as well). I know you said it didn't make much sense to you guys to have that option on a mono sequencer & something about an on-board metronome but that explanation never made any sense to me. Any drum machine connected becomes a metronome & with 2 MIDI OUTs/32 channels, that's a lot of external tracks that can be laid down in real time vs having to step program it now.

The other thing that kinda blows my mind is offering us over 1,000 patch/presets & no way to tag, categorize, sort, search them. So I have to think about how to organize presets on the Pro 3 so if I'm in the studio & want to cut a track, I can find what I want quickly before the moment is lost & that's mental energy that could be spent on the track rather than on synth logistics.

So for instance, let's say I have a melody idea. I can play it in what ... 20 seconds & have it looping if there was real-time record. If I have to step program it, depending on how complicated it is, I'm looking at a couple minutes or longer.  That's a difference on like orders of magnitude, which is substantial if stretched out over a lifetime of music-making.

I'm not sure how I want this melody voiced so let's SEQ LOCK it & audition some patches ... how long does it take to audition 1,000+ patches?  If I could just audition the lead ones, excluding pads, bass, SFX, perc, etc, it'd be so much faster but more importantly, if I have to go through 1,000 patches & don't find it in a certain amount of time, I'll probably tire & give up/settle but now my mental/creative state has been taxed a little (or a lot).

The Pro 3 workflow takes what, 3-4x as long but more importantly, it disrupts my creative flow/thought process because I don't naturally think music in step sequencer language & I don't think I'm a tiny minority there.

The thing about these workflow issues is that I don't think adding the possibilities I mentioned is disruptive to anyone's current workflow. It enhances possibilities & allows the user to roll their own workflow. No one has to use real-time record or categorize their patches if they don't want, though I guess it might be slightly more annoying to scroll through more MIDI CC options in the sequencer destination.

How much is enabling or speeding that process up worth measured resources avail to Sequential, I can't begin to speak to  ... you have a much better idea of what your end user profile is & maybe everyone's more like Richard Devine but I can say that it means EVERYTHING to me.  Creative flow, inspiration is so fleeting & ANYTHING that potentially disrupts it is very costly.

Then we've come to full-circle to the whole thing that this feature's kinda inconvenient to use, like double-tapping global vs not existing at all, which I guess is what I've mostly been on about. 

I have a few peeves about inconvenient features as well but since those are physical  -- I strongly dislike that the that the modulation controls are separated from the screen when they are so reliant on the screen for deeper mod assignments & if feels mentally disruptive to have to jump over the effects to dial in more complex mod matrix assignments.  to a lesser extent, feedback/tuning & distortion are so far apart from each other when I often use them in tandem and but I guess there were aesthetic/layout issues.

[Pym]

So I think the direction I'm going to take with this thread is to encourage each person, as they bring up a new design idea I want to explore, to start a new thread with the topic something like: "Design: Preset Categorization" and "Design: Realtime recording" so we can keep them organized cleanly. I'm still not sure how much effort I want to put into all this so I'll be picking and choosing as I have the time. I'll come back to that later

Great discussion starters, I'll reply to some of the points individually later

tl;dr - I think your posts raise a lot of interesting questions & perspectives. I'm sure I haven't thought about the UX & workflow angle as much as you so I'll just offer the view from my end.

[MKDVB]

my biggest gripe is not being able to see patch name after I've made one single edit, and can no longer get it back unless I reload it. It should be that I edit something and it returns to patch name, over and over and over or some button to return to patch name.

You can hold show & move the program knob to get back to your patch name like it was any other knob/parameter.  It's not the most elegant but beats having to jump in & out of the patch .

So I think the direction I'm going to take with this thread is to encourage each person, as they bring up a new design idea I want to explore, to start a new thread with the topic something like: "Design: Preset Categorization" and "Design: Realtime recording" so we can keep them organized cleanly. I'm still not sure how much effort I want to put into all this so I'll be picking and choosing as I have the time. I'll come back to that later

Great discussion starters, I'll reply to some of the points individually later

Yeah, sorry .. realized how unfocused I was upon re-reading my response.

[Pym]

Don't be sorry! That's actually exactly what I had in mind for this thread, to put a global and interesting discussion starter together and then fan out into specifics that will be interesting to take to a deeper level

The reason I did that with the show button is a good example of something to be discussed if someone can think of an enhancement, although I've already thought that particular one through in depth I'd be happy to share my reasonings to help people understand

my biggest gripe is not being able to see patch name after I've made one single edit, and can no longer get it back unless I reload it. It should be that I edit something and it returns to patch name, over and over and over or some button to return to patch name.

You can hold show & move the program knob to get back to your patch name like it was any other knob/parameter.  It's not the most elegant but beats having to jump in & out of the patch .

So I think the direction I'm going to take with this thread is to encourage each person, as they bring up a new design idea I want to explore, to start a new thread with the topic something like: "Design: Preset Categorization" and "Design: Realtime recording" so we can keep them organized cleanly. I'm still not sure how much effort I want to put into all this so I'll be picking and choosing as I have the time. I'll come back to that later

Great discussion starters, I'll reply to some of the points individually later

Yeah, sorry .. realized how unfocused I was upon re-reading my response.

[MKDVB]

Personally, I appreciate the consistency in the use of the SHOW button!

Like I was saying earlier though, I think many of us are conditioned via the broader market with expectations on how synths behave, like what preset boots up on power on or preset name not disappearing. I mean, preset name is a data point that doesn't need to be accessed often but people are used to seeing it all the time so not having it immediately when needed messes with them. It may seem like a minor niggle but all niggles are a possible disturbance to the flow state many of us are trying to achieve, like having a kid constantly interrupting your train of thought when you're trying to get work done.

Don't be sorry! That's actually exactly what I had in mind for this thread, to put a global and interesting discussion starter together and then fan out into specifics that will be interesting to take to a deeper level

The reason I did that with the show button is a good example of something to be discussed if someone can think of an enhancement, although I've already thought that particular one through in depth I'd be happy to share my reasonings to help people understand

my biggest gripe is not being able to see patch name after I've made one single edit, and can no longer get it back unless I reload it. It should be that I edit something and it returns to patch name, over and over and over or some button to return to patch name.

You can hold show & move the program knob to get back to your patch name like it was any other knob/parameter.  It's not the most elegant but beats having to jump in & out of the patch .

So I think the direction I'm going to take with this thread is to encourage each person, as they bring up a new design idea I want to explore, to start a new thread with the topic something like: "Design: Preset Categorization" and "Design: Realtime recording" so we can keep them organized cleanly. I'm still not sure how much effort I want to put into all this so I'll be picking and choosing as I have the time. I'll come back to that later

Great discussion starters, I'll reply to some of the points individually later

Yeah, sorry .. realized how unfocused I was upon re-reading my response.

[Pym]

This is exactly the type of data point I'm curious about and it makes total sense, thank you for giving me a 'why' answer to the issue! I will definitely take that into consideration on this and similar issues now

And the last point is exactly why I'm bringing this up as an extremely positive discussion. I actually have a very clear and concise use case example that I'm not going to talk about until I get it programmed because my guess is everybody will be REALLY stoked on the implementation and it will eliminate a lot of these issues. To get there though, I need more data, hence the thread

Like I was saying earlier though, I think many of us are conditioned via the broader market with expectations on how synths behave, like what preset boots up on power on or preset name not disappearing. I mean, preset name is a data point that doesn't need to be accessed often but people are used to seeing it all the time so not having it immediately when needed messes with them. It may seem like a minor niggle but all niggles are a possible disturbance to the flow state many of us are trying to achieve, like having a kid constantly interrupting your train of thought when you're trying to get work done.

[MKDVB]

You might as well hit us with it before Arturia steals all your thunder again!

I hate it when that happens, for real.

This is exactly the type of data point I'm curious about and it makes total sense, thank you for giving me a 'why' answer to the issue! I will definitely take that into consideration on this and similar issues now

And the last point is exactly why I'm bringing this up as an extremely positive discussion. I actually have a very clear and concise use case example that I'm not going to talk about until I get it programmed because my guess is everybody will be REALLY stoked on the implementation and it will eliminate a lot of these issues. To get there though, I need more data, hence the thread

Like I was saying earlier though, I think many of us are conditioned via the broader market with expectations on how synths behave, like what preset boots up on power on or preset name not disappearing. I mean, preset name is a data point that doesn't need to be accessed often but people are used to seeing it all the time so not having it immediately when needed messes with them. It may seem like a minor niggle but all niggles are a possible disturbance to the flow state many of us are trying to achieve, like having a kid constantly interrupting your train of thought when you're trying to get work done.

[Pym]

Nah, if anything the way they implemented it suggests my way of thinking still is pretty far ahead of theirs, but then again they have the experience now so only time will tell! They clearly have some talented people there

On this case it would be too easy to steal once I get it implemented or explain my perspective so I do have to hold off

You might as well hit us with it before Arturia steals all your thunder again!

I hate it when that happens, for real.

This is exactly the type of data point I'm curious about and it makes total sense, thank you for giving me a 'why' answer to the issue! I will definitely take that into consideration on this and similar issues now

And the last point is exactly why I'm bringing this up as an extremely positive discussion. I actually have a very clear and concise use case example that I'm not going to talk about until I get it programmed because my guess is everybody will be REALLY stoked on the implementation and it will eliminate a lot of these issues. To get there though, I need more data, hence the thread

Like I was saying earlier though, I think many of us are conditioned via the broader market with expectations on how synths behave, like what preset boots up on power on or preset name not disappearing. I mean, preset name is a data point that doesn't need to be accessed often but people are used to seeing it all the time so not having it immediately when needed messes with them. It may seem like a minor niggle but all niggles are a possible disturbance to the flow state many of us are trying to achieve, like having a kid constantly interrupting your train of thought when you're trying to get work done.

[Quatschmacher]

I’d love to see a dedicated init button if that were possible. I realise it may add cost but is surely something that people use frequently. If not, then some silk-screening which makes the two-button combination explicit on the panel would be welcome. Many users don’t seem to be aware of the shortcut.

It would be cool if an init button could either have a single replaceable patch or have two accessible functions, perhaps via short and long press - the first which loads the factory init patch, the second which loads a user-replaceable init patch.

I know it’s been said loads of times but it would be great if the factory banks were easily able to be overwritten on the synth itself.

Would there be a way to have a per-preset or per-bank memory overwrite protect function. My parallel is with the way one can write-protect individual images on a DSLR.

[Gino.Cortesi]

Adding some more thoughts on workflow. I'll mention that my profession is UX, but I'm here as a musician. 

"workflow" is a fairly overloaded term because it does not specify the scope. For example, workflow to create a bass patch on the PRO3. Workflow to create a song using a DAW with the PRO3. Workflow for setting up a jam session with 4 people in the same room (remember those days!). Workflow for creating a musical instrument for production. You get the idea...

So my main question would be: Workflow for what? (The usual When&Where, Who, What&How)

If this were a usability lab, before we observed people trying to accomplish something, we'd need recruit the right representative users, and tell them in general what we want them to try to do (without instructions, as usability is all about observing what people try to do - it's not training and closer to the opposite). My idea here is if we had a scenario Sequential wants feedback on, we could give more targeted feedback.

Open ended questions like "Is there anything that delights or annoys you?" go really well with a lab protocol as probe questions.   

With all that said, I want to frame my input to see if it helps.

When&Where: After work, at home in my make shift "music studio" (see pic)
Who: 50 something amateur musician 
What&How: Need to make a few catchy riff ideas for a new track, and I'm working with another musician on it. I need to create several of these, and upload the audio clips to our shared Google Drive. I want to leverage the PRO3 for this, and have 2 days to do it.

Plug in cables to my Macbook Pro, and power on my equipment
Start Bitwig Studio (which starts with a blank template)
On the Digitakt (DT for short) set the program to the next blank user one for the PRO3
- On the DT the encoder scrolls through the programs too fast, need to write Elektron about it.
- I do this because I've lost programs I'm editing many times, as a program change just jumps to the next patch
- I've also lost work because I thought increment and decrement were for values in the mod matrix, and not for program changes. Lesson learned. 

On the PRO3 init the program and enter a name
+ Like the shortcut down+latch to do this
- Clearing the name should be easier and takes 13 clicks
- Enter in GC## where ## is the program number. Entering numbers takes longer, love the idea of using the keyboard notes to jump to values.
+ I like being able to see the program number when saving, as I use it to increment my patches. I go back and rename
programs GC15 ---to---> Snth-6-Bass when I use it on a real track. Snth is our band name, and we number our
songs to keep track of resources.

Make a unique rhythm on the DT. I typically use the init program on the PRO3 to do this, and lower the octave and the filter just to sketch things. I play on the Argon8 which goes through the DT and it's my main midi controller.
- I record on the DT sequencer because it's my main sequencer, but also the PRO3 sequencer does not have real time recording. That makes it hard to do off beat rhythms.
+ I really like gating the PRO3 sequencer from the DT, that's important as you can quickly mute tracks on the DT and it works with the PRO3 sequencer.
 
Once I have a rhythm sequence I like, start shaping the voice/program on the PRO3. I'll do a bass program for this one.
In this case I turn all 3 OSCs to the lowest octave, then move the filter to 10 o'clock, add some filter envelope while tapping a note. I then mix the OSCs, and mess with the shape, and shape-mods for OSC1 and OSC2. I typically use OSC3 as a sine sub osc. Once I get something decent, I press write twice.
- I wish we could set what program is used for the init program. As I want OSC3 to default to sine, and I tend to clear the sequencer by recording 1 note (because the default sequencer pattern is cheesy, and it annoys me when I hear it . 
+ I love the sound of the VCO's, and the filter. I can make interesting bass patches that i like very quickly.   
+ I use Compare while the sequencer is running to see if I like my edits. Very cool that you can even load a different program with Compare, and still go back to the patch you are editing.

Now it's time to record the idea to audio.
Add basic drums on the DT if needed.
Record in Bitwig (arm the DT audio track, press play).
While recoding, mess with real-time controls on the PRO3 (filter, effects mix, etc).
After a few minutes of messing around, listen to it, choose the best parts (to get it down to around 30 seconds of audio).
Export as a WAV to Google Drive

I repeat most of those steps above until I have several audio clips posted. Sometimes this is over a few days. When ready I then send an e-mail to the other musician with links to the clips to see what they think (meanwhile they are doing the same, and sending me clips to check out).

This is when we are writing ideas for a new track, it changes when we go to the next phase which is making what we call a "skeleton track" which is just the structure of the song at full length with very basic voices.

You can check out one of our finished tracks here: https://www.youtube.com/watch?v=7ISnH0Q4HGU

Best regards,

Gino

[hiddenagenda]

• What is the current workflow? Not clicking Global because I'm lazy
• What part of it do you want to change? Ideally the last patch would load in case of a brown out, someone tripping over cables, etc, but also just to pick up whatever I was working on before
• How does that impact people who are used to the current workflow? I don't know but I suppose there could be a setting for which behavior is preferred.
• In what contexts is this an improvement to efficiency? It's a minor efficiency gain
• In what contexts does this make things more complicated? My guess is that few people are clicking Global before each power down so I doubt it makes things more complicated but maybe other uses will have different feedback.

Regardless of the solution decided on, this is a minor issue for me.

Agreed!