Please familiarise yourself with the forum, including policy on feature requests, rules & guidelines
Is this synth feature removed in FW 3.0 ? + off topic discussion
OdoSendaidokai
BerlinPosts: 323
I was wondering when using a synth track, that in an earlier firmware when you start changing some parameters the synths name was changed from "9" to e.g. "9a" then you could create a new clip with a fresh "9" synth. But now you are not able to select the synth "9" when it is already used for a clip. If you try to select the "9" it jumps directly from 8 to 10.
Is this a bug? Or is this a removed "feature" in FW 3.0 ? And If it is removed, why?
I'm pretty sure that one or the other song I did is now broken. (too many to check them all tonight)
Could maybe someone check that behaviour on his FW 3.0 ?
Odo Sendaidokai from Berlin
Post edited by OdoSendaidokai on
Comments
Removed. Instead, if you want to clone a patch (and achieve what you want), while in the preset loading interface (Load+Synth/Kit) select and hold the load button on the preset you want to clone, screen will say CLONe
Select that
~ Distinguished Delugate ᕕ( ◎_◎)ᕗ
Thanks for that workaround. 🌻 I can't find the removal in the changelog nor I can find a proper description in the manual. And I can do only 2 instances of a synth sound. When I try to create a 3rd clip with your workaround it doesn't suggest "CLONE" it just says "FILE" and I don't know what to do then.
In my opinion, this is broken.
Odo Sendaidokai from Berlin
Its not a workaround, its the new method to achieve the same thing
If you want to clone a preset, make new synth clip first, then via the loading interface bring up the preset that you already have in another clip that you want to clone, then hold load and clone it. Repeat the process as you need. I just did, didn't get any FILE message
~ Distinguished Delugate ᕕ( ◎_◎)ᕗ
You might get trouble trying to clone a clone, I just spoke to Rohan about that, that'll probably be resolved in the future.
Just clone the original preset
~ Distinguished Delugate ᕕ( ◎_◎)ᕗ
Hmm I don't understand why the former far more elegant way was removed? The current "solution" is really longwinded. For what reason was this done?
Odo Sendaidokai from Berlin
Because many people DIDN'T like that a new patch was automatically created and not having the choice to do so, me included. This is the way it is now
And I have to disagree that its longwinded, its a simple process of duplicating the patches, just not automatic without any control over it.
~ Distinguished Delugate ᕕ( ◎_◎)ᕗ
Ok, but wouldn't it been better, to do it like e.g. this
This workflow is much more intuitive and similar to the old way but without creating automatically new patches. And you don't have to press several new hotkeys.
Odo Sendaidokai from Berlin
huh, yeah I preferred the old way for sure. Something like what is proposed above sounds like it elegantly addresses both issues.
Agree with @OdoSendaidokai the new way seems a bit of a step back, I prefer the old way or at least a choice, like the one proposed.
the change removed some automatic preset renaming logic which could get confusing. i find it more clear now.
I don't think that's better
But you're entitled to your opinion. What if one is using presets with alphanumerical names? I wouldn't want a potential new #2 of every preset when I'm scrolling through them after creating a clip.
~ Distinguished Delugate ᕕ( ◎_◎)ᕗ
LOL thank you, you're entitled to your opinion too. Only because there was a decision from the devs doesn't make it right. Everybody can be right or wrong.
Just count the steps between the two ways of doing this and remember, that this device was targeted for live performances. And then think about if it is such a good way to create ways that need more steps and more fingers to achieve the same thing.
off topic
At the end I have the impression that developing features and the real discussion is happening in the walled garden of facebook and absolutely not here in this free forum. I slowly lose interest to think about how things could be better or what could be done to make this wonderful deluge even better or visiting the forum. Or are the two facebook forums as well calm like this forum is?
I'm a little disappointed about the steady hunt for new features and leaving really old features/problems like the half implemented MIDI untouched. Or make the song and the arranger more complete (topic automation editing ).
Ok, everybody has his own favorites and these are mine. But it is a little frustrating to have a bunch of features and when you start using it intense, you really miss some fundamentals to can use it seriously. Because since it was introduced, it feels like there was/is no real progress or interest to improve that feature. I really would love to see the next big firmware version with no new features, just heavily improving and completing the really great ideas and features that were introduced since the beginning.
Odo Sendaidokai from Berlin
“really would love to see the next big firmware version with no new features, just heavily improving and completing the really great ideas and features that were introduced since the beginning”
i feel the same.
to be fair there goes a lot of effort into making Deluge stable and bug free. i agree it still is a major pita a to apply a change to all clones. i dont agree with you what exactly should be done next and how, neither would anybody with me. i d surely like to see Rohan could adress more of our evergreen suggestions, there have to be some that are easy to implement and fit into their vision.
We're constantly working hard in the beta group on facebook to advance the development. Its not a "walled garden", you're welcome to join like anyone, and do your part to speed up the work (right now there's no beta since the bugfix was just released). We're a team doing the testing, but there's one man developing the software, and one man can only do so much at a time. Keep in mind, the Deluge started as a kickstarter project, has grown insanely in the 2 years since that, and when one buys a Deluge one doesn't buy a finished box, but a lifetime software license to an ongoing work in progress that has enormous potential.
There are TONS of suggestions, and there are heaps of room for expansion and improvement. Synthstrom is well aware of all thinkable things that people have come up with, but many people want widely different things.
For each update, there are both new features and improvements to existing ones - always.
I've wanted looping capabilities since I got the Deluge 2 years ago, but I too would like improved midi functionality, and so on.
~ Distinguished Delugate ᕕ( ◎_◎)ᕗ
We had this discussion here on the forum several times. Facebook IS a walled garden who is abusing heavily the data of its users. You can nearly read it every week in a lot newspapers. That's why a lot of the people here in the forum don't use any of facebooks services (Facebook, Whatsapp, Instagram, Messenger). So upon our choice to not sell our personal life, we don't have the choice to help on developing. But we fully respect that Synthstrom Audible is using this infrastructure. No hard feelings here. 🌻
See, we are on a similar page like @amiga909 said, some things are easy to implement (like the full midi implementation definition or the standardization of 128 Steps instead of 50) and I don't really understand why this task is still open in firmware 3. This is a very essential thing, because a lot people love to use the deluge in a studio environment or on a complex livesets and they are still limited because there seems no interest on finishing an easy task (low hanging fruit).
Odo Sendaidokai from Berlin
These forums are the only place we come to and consider ideas. We remove any feature suggestion post immediately that is posted on FB. Any of the users there will attest. Including in the beta testing discussion.
There is nothing that would be 'easy' to implement
See what Ian said about "easy to implement".
About the 128 vs 50 steps, Rohan just confirmed that the parameters do indeed have 128 distinct midi values on the gold knobs and via midi even though the Deluge Select knob deals in 50. The logic behind that is simply less numbers to scroll through with the select knob - the gold knobs still deal in the full range.
And about midi implementation, Rohan hasn't specified or confirmed anything, but that's quite complex as a standard midi implementation wouldn't work since the Deluge is so flexible and used differently by different people. Eventually, we'll surely get a smart solution, but it definitely isn't simple or straightforward to do.
~ Distinguished Delugate ᕕ( ◎_◎)ᕗ
I respect your dedication @Icoustik , but please just read your post yourself. You are talking about a professional machine. And in FW 3 there is still the serious decision to reduce 128 steps to 50 so you can't fade in e.g. noise because it bumps in because people are too lazy to scroll 128 steps? Come on. Lot people were asking for 128 steps in this forum for a long time. There are a lot of possibilities to "shift down" 128 to half like 64 what would be logic if you really need it. Or why not make it configurable, when many people asking for it.
It's not that there need to be made a midi implementation, it is already there. It is only to complete the midi definition. You can find a lot information in this forum too. As well from programmers.
Look I don't want to start an argument here. That is absolutely not my intention! And I highly respect the wonderful work of Rohan and the beautiful design of the Deluge. 🌻
I'm just asking to focus on improving important existing features the same way like on developing more great funky features. Both are good and both are important in different ways for different people.
Odo Sendaidokai from Berlin
The difficulty with what you're asking is highlighted by this very post you started. Any change to any existing workflow is significantly more difficult than creating a new one.
We always consider everything and don't worry, haha, we hear everyones beefs and know everyones issues, shit is WAY more complex than people realise.
We just tried to 'improve' the cloning functionality which many many people have complained about...like, lol, easily one of the things which has confused people the most of any UI...but, haha, see the mess it causes to existing established workflows, even when you improve something
Are you serious?? Reducing a more or less standard resolution to rather uncommon values in favor of the users laziness in regard of using the select knob for scrolling is not a real advantage compared to other gear still sticking to that resolution. Come on
In my view this was a wrong decision from the beginning anyway. And it is clear that changing this would break many configurations. However, I would prefer dealing with this issue better now than never.
((qp))
well, only Synthstrom knows what is easy to change and what is hard. all i know is i wouldnt underestimate the complexity of this software, any change can be hard. sometimes a change can be trivial but affect a part of the code that needs a rewrite on the long term.
at least some people did appreciate the change
could go on forever about the clone problems but i dont want to support threads that dont try to improve existing suggestion threads. if Synthstrom should improve existing features i should try to improve existing suggestions too.
The values in the XML are 8 digit hex numbers. If the synth engine actually uses all those numbers there are a lot more than 128 (4294967295).
I'm not super bothered, but it might be nice to have the 'double stage' parameters like used on the transpose for other stuff like the envelopes.
One thing to bear in mind is that the last firmware update was very much a non-synth engine one. We've been given some hints that there are synth improvements planned - like a couple of extra labels on the new panels. I'd say there's a good chance that the NY2020 update is going concentrate on that area.
I'd still like an enhanced LPF, although I appreciate that there's always the tradeoff between higher quality and performance.
I see haha, a completion of the MIDI implementation (incl clearing up the global/local definition) and 50 to 128 steps is much more complex than developing a full arranger and a full looper.
Haha lol funny.
I see where this is going, so let's better end this discussion. Thank you all for joining this off topic discourse.
Odo Sendaidokai from Berlin
Totally agree with the 50 thing. I think I said this way back when I first got mine. Needs to be higher resolution, generally, especially Envelope parameters and 0-127 is literally 'industry standard', if such a thing exists. And there's no reason for that change to break anyone's stuff - the values could be scaled on loading (based on OS version number of saved file) - 0=0, 25=64, 50=127 etc.
What I liked about the previous track cloning workflow is that if I felt that I had strayed too far from the original sound and wanted to get back again, it was just a single step on the encoder. After using the new workflow a bit, it's not so bad but I have to remember to explicitly clone a track if I intend to make any changes to it as some point, which is less convenient.
Yeah, that's what I've been thinking. The rough envelopes and low param resolution are okay but the logical path to 127 is fairly simple (and I'm sure the development path is 10x more complicated).
You don't seem to understand. The gold knobs produce 128 steps, the SELECT knob with the same parameter number when on screen is 50. Get what I'm saying?
So if you use the gold knobs or an external midi knob, it IS indeed 128 steps, and you can choose whether you want to edit the parameter with the select knob, a gold knob or a midi controller.
~ Distinguished Delugate ᕕ( ◎_◎)ᕗ
See my reply above
~ Distinguished Delugate ᕕ( ◎_◎)ᕗ
And you really mean to map a gold knob whenever I want to fine tune a parameter (e.g. envelope stages, or whatever...)? And where will I be able to check the absolute value then?
Seems quite unconvenient to me.
((qp))
Exactly. And while I'm hearing a lot of rationalization about why we don't "need" 127 steps, I have yet to hear why 50 is so necessary. It's counter-intuitive that the value you can adjust with precision (via shift+whatever) is arbitrarily scaled to 50 while the value you can only adjust without precision has more value intervals.