Please familiarise yourself with the forum, including policy on feature requests, rules & guidelines

How do I make realtime synth parameter changes apply to all tracks that use the same synth preset?

6
OmskInfoOmskInfo Berlin, DeutschlandPosts: 25

Firmware version 2.1.4

If anyone can help me here, you'd be my hero as this is driving me absolutely crazy. To help make my point, I will first illustrate a simple workflow using an external MIDI synth, which works as expected, and then I'll compare that to using the Deluge's internal synth (which doesn't work as expected):

First, I've got an external synth (let's say it's my Virus TI) connected to the MIDI Out of the Deluge. I create two tracks on the Deluge and set them both to Channel 1A—this means that both tracks will output their notes on Channel 1, but only one of the tracks can play at a time. On the first track, I program a simple pattern that will basically be repeating itself for the majority of the song. On the second track, I program a variation that I will want to trigger from time-to-time to spice things up (like a drum fill, but on the synth part).

I press play on the Deluge and play track 1 to the Virus. The Virus is playing the notes I've programmed and, while it's playing, I start to twist the knobs on the Virus to change the sound, like opening up the filter or increasing distortion (the exact parameters don't matter—this is just an example). Now, when I get to the point on the song where I want to spice things up, I trigger track 2 on the Deluge. The new part starts playing to the Virus while the previous part stops. The critical bit: The new part is playing on the Virus using the same/current state of its parameters. For example, if I had slowly increased the filter cutoff to 127 while track 1 was playing and then triggered track 2, now track 2 would be playing the sound with the filter cutoff still at 127. "The new track picks up where the last one left off" in terms of the sound it's playing (which is natural, of course, since the Virus has just been receiving MIDI notes and doesn't have any idea of which "track" this came from on the MIDI host).

Now, let's compare this to the same process with the Deluge's internal synth:

I set up two tracks on the Deluge and set them to the same preset. As above, because the two tracks (supposedly) share the same preset, only one of the tracks can be playing at any given time. Track 1 is the basic repeating part and track 2 is again the spicy "interesting/fill-in" part.

I press play on the Deluge and play track 1. While it's playing, I start to increase the cutoff on the synth to make the sound brighter. Then, when I get to the point in the song where I want to spice things up, I trigger track 2. Track 2 starts to play but jumps back to the original preset sound before I had started tweaking the cutoff. As a result, this wonderful build-up I'd created with the first track is suddenly killed when the synth reverts to playing the original mellow sound with the second track.

The reason for this, it seems, is that, the moment I tweak the cutoff when playing track 1, this instantly and automatically creates a "dirty", "temporary", or "alternate" version of the synth preset (which can be seen by the preset suddenly getting an "A" suffix added to its number). Even though it looks like tracks 1 and 2 are sharing the same preset since only one track can play the synth preset at any time and because they both have "A" in their names, they're actually not sharing it at all since tweaks applied to the preset on one track aren't "shared" with any other tracks using the same preset; each track just has its own copy of the preset which doesn't actually stay in sync across tracks. Thus, the musically-expressive and intuitive workflow that is possible with an external MIDI synth is not possible with the internal synths (as far as I can tell).

Am I missing something? Is there a way to get multiple tracks that are sharing the same preset to also share any real-time changes made to that preset?

Thanks!

Comments

  • 1
    amiga909amiga909 Central EuropePosts: 1,078
    edited August 2019

    its sadly one of the details Deluge did not get right. it is complicated, we have to acknowledge Deluge solves another problem: overwriting a preset in Song A does not affect the same preset in Song B
    many threads about this, for example:

    in v3 things are better, automatic renaming and option to force-load a preset as clone help, the problem you describe is still there, maybe a new option in LOAD load-from-disk would help. still we dont get basic stuff like add a new sample in kit, and have that sample in every cloned clip, still we had to reload every cloned clip.

    Post edited by amiga909 on
  • 0
    OmskInfoOmskInfo Berlin, DeutschlandPosts: 25

    Thanks for pointing me to those threads, amiga909. I didn't realize "clone track" was quite the same issue I was discussing, but it definitely is now that I've read through the treads. Glad I'm not the only one bashing my head against the button matrix on this one.

    I originally thought the relationship between presets and tracks was clever, but now I'm feeling that it's causing more problems than it solves. Would be nicer to just have a preset assigned to a synth, and then 1 or more tracks assigned to that synth.

  • 1
    amiga909amiga909 Central EuropePosts: 1,078

    @OmskInfo said:

    I originally thought the relationship between presets and tracks was clever, but now I'm feeling that it's causing more problems than it solves. Would be nicer to just have a preset assigned to a synth, and then 1 or more tracks assigned to that synth.

    Yeah, agreed it is what i expected at first. Usually you load up a VSTi and its patterns (Delugian: clips) share this instrument, the clips being just notes and automation.
    Some param changes do affect all clones (most params that cant be learned, like delay type), this mix is really bad imho. i'd prefer all params are shared or none. however, nothing is perfect. don't know if u already tried v3 beta, there is a new option "Clone" to force Deluge to load an already used preset as a new preset.
    what do you think about the idea of a "Card" option in the preset load menu (in v3 preset load changes)? this option would be only available if the preset is stored in SYNTH or KIT folders (Deluge has temporary presets that are attached to a Song which prevents altering other Songs when changing a preset)
    then the workflow for your thread title would go like this:

    • say we have 6 clips of preset "bass1". change cutoff in one clip, overwrite preset as "bass1"
    • in all other clip clones, for every clip select "bass1", long-press LOAD + choose "Card". now the new cutoff setting is applied on all clips.
    • less cumbersome and faster than the reported workarounds (check older threads)
  • 1
    KenoubiKenoubi United StatesBeta Tester Posts: 46

    I have to agree this behavior is simply a bug; no one could reasonably want it to work this way. If we had better ways to control automation (particularly, an easy way to turn on automation for a particular parameter, but just copy the current value to the whole clip), then I think it would be more useful as well as simpler for all parameters to always be shared except for automated parameters.

    Anyway, I thought of another workaround, which is useless in a live setting but might help someone who's made a total hash of a saved song this way. (Warning, this will probably delete all your automation!)

    1. In the clip whose parameters you want to keep, save the synth as a preset.
    2. Change all the clips you need to fix to MIDI clips.
    3. Save the song.
    4. Load the song. (Yes, you actually have to do this, otherwise it somehow magically remembers the parameter values in the next step.)
    5. Change all the clips back to the preset you saved in step 1.

    Voila, all the parameters should be the same in all the clips. This is basically impossible to do otherwise if you don't know exactly which parameters in which clips you might have edited.

  • 0
    OmskInfoOmskInfo Berlin, DeutschlandPosts: 25

    @amiga909 said:
    what do you think about the idea of a "Card" option in the preset load menu (in v3 preset load changes)?

    I didn't quite get what you meant with this "Card" option the first few times I read it, and it's still not quite what I'm looking for. I think all I'm looking for is a parameter in the Synth Edit menu called "Link" which would link any synth changes across all tracks using that preset. There are already some synth parameters that are shared across tracks, so enabling this option would simply force them all to sync without having to do any particular saving of the preset back to the card first. Just load up a synth preset, enable this "Link" parameter in the Synth Edit menu, and then continue working as normal, making as many clones as you want (or make the clones and then go back an enable Link—either way). Tweak the sound on one track, and hear the same state when switching to any other track with that preset. This setting is saved as part of the song, not the preset, therefore all pre-existing songs aren't affected even if they use an instance of that same preset.

  • 1
    amiga909amiga909 Central EuropePosts: 1,078
    edited August 2019

    interesting workaround, doesnt need to create useless temporary presets.

    totally agree it should simply work like in all DAWs i know: a param change affects all clones while leaving other Songs intact (you would not want to resave a preset in Song A and get Song B, which uses the same preset, altered in any way).
    i dont see a good way how it could be done without breaking backwards compatibility. imagine u have an old Song that relies on the current system and u want to add a new instrument with the new „true-clone“ mode. possibly a setting for every instrument if its „true-clone“ or „old-version“ but that seems cumbersome. or a way to convert old XMLs... for the current UX my best bet is to add a „Card“ option to the „Clone“ option in v3 synth/kit LOAD menu.

    Post edited by amiga909 on
  • 1
    OmskInfoOmskInfo Berlin, DeutschlandPosts: 25

    @amiga909 said:
    i dont see a good way how it could be done without breaking backwards compatibility. imagine u have an old Song that relies on the current system and u want to add a new instrument with the new „true-clone“ mode.

    I wasn't suggesting that this is a global parameter or song-wide parameter; I was suggesting that this is a synth/preset parameter, so you explicitly need to set it for any preset where you want it to have this shared/linked behavior. Meaning: you can actually have both worlds existing simultaneously in the same song if you wanted to!

    For example, I could load Preset 1 into a track, enable Link in the Synth Edit menu, and make two cloned tracks of it which then have the new shared/linked behavior. I could then load Preset 2 into a new track, leave Link turned off, and make two cloned tracks which then exhibit the old behavior. Win/win.

    As this would be a new parameter, the value would be set by default to "off" or "unlinked" in all old songs meaning that they still perform as usual (though you could edit them to enable this behavior where desired and re-save the song). For faster workflow, in the Global Settings menu, there could be a "default link mode" option which determines how this parameter will be set for all new tracks made (for those of us who would be using the linked mode most of the time and only choose the unlinked mode in special circumstances).

  • 1
    amiga909amiga909 Central EuropePosts: 1,078

    interesting workaround with midi, doesnt need to create useless temporary presets.

    sorry OmskInfo, didnt see ur latest post when replying,
    yeah, maybe a setting for every instrument if its „true-clone“ = LINK or „old-version“ could be the best way.
    having a mix between LINKed and unlinked instruments feels strange to me. but when opening an old song i still could once convert all instruments to LINK, possibly saving some old clones as new presets. wouldnt mind that work to get the LINK feature.

  • 0
    amiga909amiga909 Central EuropePosts: 1,078
    edited August 2019

    the „Card“ idea comes from another issue discussed in a v3 beta chat. „Card“ means the preset is loaded from the SYNTH/KIT folders on the sd card. problem is: if a Song A and B use „tb303“ and u resave „tb303“ in Song A with a different sound, u cannot get that in Song B, Song B still has the version it had before and u cannot access the previously resaved „tb303“ version in the Load menu. To overcome this „Card“ allows to load tht previously saved version.
    For this use case („true clone“) u could align cloned clips via loading from „Card“, speeding up the workaround, still u had to do it for every single clone.
    i agree LINK is much better for this use case.

    Post edited by amiga909 on
  • 0
    KenoubiKenoubi United StatesBeta Tester Posts: 46
    edited August 2019

    @amiga909 said:
    interesting workaround, doesnt need to create useless temporary presets.

    totally agree it should simply work like in all DAWs i know: a param change affects all clones while leaving other Songs intact (you would not want to resave a preset in Song A and get Song B, which uses the same preset, altered in any way).
    i dont see a good way how it could be done without breaking backwards compatibility. imagine u have an old Song that relies on the current system and u want to add a new instrument with the new „true-clone“ mode. possibly a setting for every instrument if its „true-clone“ or „old-version“ but that seems cumbersome. or a way to convert old XMLs... for the current UX my best bet is to add a „Card“ option to the „Clone“ option in v3 synth/kit LOAD menu.

    IMO the existing behavior is so broken that I'd simply make it part of the v2 -> v3 (or vN -> vN+1) XML import process: when loading a v2 song, make every parameter in a clip that has a parameter value set for that specific clip be automated for that clip, with the automation just setting it to whatever the specific value is, and from that point on enforce that parameters are ALWAYS linked except for automated parameters (actually, even automated parameters should be linked, but the automation should override the linked value; if you delete the automation you should get back the linked value).

    Edited to add: If you actually WANT the existing behavior, except not broken (that is, unlinking ALL of the parameters, not some arbitrary subset), the "Clone" option that has apparently already been added in v3 would let you do just that.

    Post edited by Kenoubi on
  • 0
    MaxOSMaxOS Los AngelesPosts: 50

    Thank you for clearly describing this problem. It's been driving me absolutely insane as well. It's actually the only real issue I have with the workflow.

  • 1
    amiga909amiga909 Central EuropePosts: 1,078

    emotional topic for me :) "half-breed clones" are the single, really dark spot the Deluge has IMHO.

    @Kenoubi said:

    Edited to add: If you actually WANT the existing behavior, except not broken (that is, unlinking ALL of the parameters, not some arbitrary subset), the "Clone" option that has apparently already been added in v3 would let you do just that.

    Loading as a new instrument changes the "choke group behavior" though, means clips would not play exclusively anymore (mute each other).
    If possible to convert old songs into a new LINK mode automagically this would be fantastic.
    i see 2 issues
    1. it may be impossible to preserve the composition as it was in some cases: for example by now a Kit clone may have different sample rows (adding/removing a sample row is per clip, not global), of course u could automatically create a preset that has all samples, still the row order would change.

    2: some people might have a business with their Deluge songs and might rely on the current implementation for their gigs. for example a performer might like to destroy a clip with bitcrush and then switch to a cloned clip, by now he wouldnt get the bitcrush, with LINK he would.

    after all having LINK or unLINKED as an option makes sense now but not the most elegant, being able to mix both modes to ensure backwards compatibility works but it is confusing if you a look at it from a new user perspective.
    for me the idea of forcing LINK mode and removing the current mode fits the best, even if it means it changes some details in my old songs. in german there is a saying: better an end with a shock than a never ending shock :)

    some more details: should LINK mode apply to audio tracks (v3), midi or cv? i think only synth and kit.
    are white instances in arranger also subject to LINK mode? i'd say yes.

    Above all i'd love to get LINK or XML-import any time, both are really nice ideas. I dont agree this is just a bug, it is more of a fundamental design problem, nor that it can be easily fixed but i dont know the code of course.

    Really hope Rohan could get us some insights here: is the "half-breed clone" thing recognized as a problem? what was the reasoning it was implemented this way? if hard to change, why?

  • 1
    KenoubiKenoubi United StatesBeta Tester Posts: 46
    edited August 2019

    @amiga909 said:
    emotional topic for me :) "half-breed clones" are the single, really dark spot the Deluge has IMHO.

    @Kenoubi said:

    Edited to add: If you actually WANT the existing behavior, except not broken (that is, unlinking ALL of the parameters, not some arbitrary subset), the "Clone" option that has apparently already been added in v3 would let you do just that.

    Loading as a new instrument changes the "choke group behavior" though, means clips would not play exclusively anymore (mute each other).
    If possible to convert old songs into a new LINK mode automagically this would be fantastic.
    i see 2 issues
    1. it may be impossible to preserve the composition as it was in some cases: for example by now a Kit clone may have different sample rows (adding/removing a sample row is per clip, not global), of course u could automatically create a preset that has all samples, still the row order would change.

    2: some people might have a business with their Deluge songs and might rely on the current implementation for their gigs. for example a performer might like to destroy a clip with bitcrush and then switch to a cloned clip, by now he wouldnt get the bitcrush, with LINK he would.

    I do have a lot of sympathy for that use case, but wouldn't that person want to extensively test a major firmware update like this before using it in a live setting, and wouldn't a big behavior change like this be blindingly obvious? Then they just need a way to downgrade until they have time to deal with the changes that have been made. (I did also say most uses of this could be translated into automation. I don't know if bitcrush is automatable, but if not it would theoretically make sense to make it automatable so there's a way to translate this into the new format. But I'm pretty sure that wouldn't be worth the time it would take to do it, unless that's the only way to make fixing this viable.)

    after all having LINK or unLINKED as an option makes sense now but not the most elegant, being able to mix both modes to ensure backwards compatibility works but it is confusing if you a look at it from a new user perspective.
    for me the idea of forcing LINK mode and removing the current mode fits the best, even if it means it changes some details in my old songs. in german there is a saying: better an end with a shock than a never ending shock :)

    some more details: should LINK mode apply to audio tracks (v3), midi or cv? i think only synth and kit.
    are white instances in arranger also subject to LINK mode? i'd say yes.

    I don't see any reason it would apply to MIDI or CV. Audio tracks, if they can be grouped into "instruments" that have a predefined set of effects and that choke one another, then yes, link mode (or link behavior in general) would apply. (I'm not a v3 beta tester so I don't know exactly how audio tracks work.)

    Above all i'd love to get LINK or XML-import any time, both are really nice ideas. I dont agree this is just a bug, it is more of a fundamental design problem, nor that it can be easily fixed but i dont know the code of course.

    I guess you're right; a design choice that seems completely bizarre and unintuitive to some (or even most) of your users still isn't a bug per se. I can't really see why it would be that hard to fix other than trying to maintain backwards compatibility though, if there were a will to do it. I mean, it already knows how to share some parameters, and it already stores the parameters in the preset. Seems like all it would have to do is apply exactly the same code that's already used for (e.g.) transpose to all of the parameters.

    Really hope Rohan could get us some insights here: is the "half-breed clone" thing recognized as a problem? what was the reasoning it was implemented this way? if hard to change, why?

    I can sorta see why it would have seemed like a good idea at the time. In fact, depending on your workflow it might never bite you at all (I've barely noticed it when I'm actually using the Deluge so far, although I think that might change as I start to tweak more parameters in particular clips to keep things from sounding too monotonous throughout a whole song).

    Post edited by Kenoubi on
  • 0
    MaxOSMaxOS Los AngelesPosts: 50

    Has anyone found any improvement on this issue in Version 3.0?

  • 0
    KenoubiKenoubi United StatesBeta Tester Posts: 46

    @Kenoubi said:
    If we had better ways to control automation (particularly, an easy way to turn on automation for a particular parameter, but just copy the current value to the whole clip), then I think it would be more useful as well as simpler for all parameters to always be shared except for automated parameters.

    It occurs to me that I was making this overly complicated. We can get behavior that's almost the same as what we have now but still fixes this problem:

    1. Turning a gold knob should make that parameter automated, always, not just when record is on. (Record retains its meaning of "if playing, continuously record the parameter as it changes".)
    2. Deleting automation should also reset the parameter's value to the global preset parameter value.
    3. Saving a preset should overwrite the global preset parameter values (but nothing else should).

    The first change should be practically unobservable, except in two cases: when you copy automation and when you delete it. Being able to copy an edited parameter value (even if it's edited to a fixed value) is an added feature that I don't think anyone could really object to. And I think it's not very realistic either for anyone to be relying on the current behavior of deleting automation or saving presets.

  • 1
    DrLucidiousDrLucidious SwitzerlandPosts: 3

    I think it is even simpler: The "affect entire" button could be made to cycle across three knobs:

    • Off
    • Affect entire clip
    • Affect all clip clones (led can blink to indicate this, similar to arranger mode).

    The first two modes are what is currently implemented. The third mode will affect all clones, which would allow the desired behaviour desired by many people: This allows both changing parameters across clones (e.g. level, filters) but also adding new samples to kits.
    Furthermore, the "affect all clip clones" could be enabled by default in "arranger mode". Furthermore, when "recording" in "arranger mode", the parameter settings could be prevented from resetting when switching between clones.

    IMHO this should be relatively easy to implement without breaking any backwards compatibility.

  • 1
    OmskInfoOmskInfo Berlin, DeutschlandPosts: 25

    I guess it's pretty obvious that, as we approach 2 years for this "easy to implement" idea, it will never happen. Really disappointed.

  • 0
    MaxOSMaxOS Los AngelesPosts: 50

    @OmskInfo said:
    I guess it's pretty obvious that, as we approach 2 years for this "easy to implement" idea, it will never happen. Really disappointed.

    I wonder if we can do a petition or something.

Sign In or Register to comment.