Free FM Synthesizer Dexed (VST Windows and Mac)

VST, AU, AAX, CLAP, etc. Plugin Virtual Instruments Discussion
Post Reply New Topic
RELATED
PRODUCTS
Dexed

Post

fmr wrote:
overhishead wrote:I noticed that theres a lot of folks wanting the gui to look good, but really if this is an emulation, things such as realtime parameter modification with a slider, and the AMS function should be a few tiers above in priority.

as long as you're emulating, why not adhere to the original? Image

getting crazy with a gui is great and everything, but i am rooting for the development of a complete emulation, which is the stated goal. and well, sound and function is first and foremost. as long as we're being sticklers about the 32 patch limit and all.
Do you REALLY want THAT? :-o Have you ever wondered why there were so many software editors for the DX7? And why more than 90% of the DX7s that went to service to Yamaha had the initial sounds untouched?
I can only agree. One slider ? In the 21st Century ? Not for me, not for most I would think.

Post

lest I am drowned in guffaws and harumphs and being bullied by 15 year olds:

1) AMS (that parameter in each voice, in case you actually tried Dexed) is broken
2) Dexed could easily hold several banks, without breaking compatibility, using the method that hexter did. (and hexter is also open source i believe)
3) The final gasket in the engine is realtime "timbre" changes, which was accomplished with one slider on the Dx7, is awesome.
4) realtime sysex control to an actual Dx7 and then you've got a sick emulation.

Post

overhishead wrote:lest I am drowned in guffaws and harumphs and being bullied by 15 year olds:
First, I am not 15 years old, and was already around synths when the DX7 came out (yes, I am THAT old).
overhishead wrote:1) AMS (that parameter in each voice, in case you actually tried Dexed) is broken
It is, and that has already acknowledge by the developer, that told it is in the to do list - THIS IS VERSION 0.8
overhishead wrote:2) Dexed could easily hold several banks, without breaking compatibility, using the method that hexter did. (and hexter is also open source i believe)
Don't know Hexter, but since it is so good, why the need for Dexed? And is Hexter able to save files compatible with the DX7?
overhishead wrote:3) The final gasket in the engine is realtime "timbre" changes, which was accomplished with one slider on the Dx7, is awesome.
4) realtime sysex control to an actual Dx7 and then you've got a sick emulation.
This can be accomplished (and I hope it will) much better and easily with MIDI learning. I personally don't care to have a slider in the GUI which I will not use EVER, but care to have the possibility to address any parameter I want to MIDI controls like velocity, aftertouch, pitch wheel, modulation wheel, the several control sliders that modern MIDI keyboard controllers have, or DAW controls.

About the realtime sysex send to an actual DX7, is the DX7 even able to respond to that?
Last edited by fmr on Thu Oct 30, 2014 10:07 am, edited 1 time in total.
Fernando (FMR)

Post

fmr wrote:Another suggestion. When we are working in a patch that we opened in a bank, when we choose to save it (STORE), DeXed should place itself in the slot location of the patch opened, NOT in the first location of the bank. If we are not aware, we can accidentally delete the first patch from the bank.
Another good suggestion. Dexed is first and foremost a patch librarian for the hardware DX7
Intel Core2 Quad CPU + 4 GIG RAM

Post

Thanks everyone, I love doing open source !
Spitfire31 wrote:A small GUI idea: How about a strenghtening of the highlight on the horisontal (top) edge of each operator module and a similar highlight on the left vertical edge, simulating a light source diagonally from top left (a common convention)? It might help to separate the different GUI components, to aid visually impaired synthesists like our ambitious friend Black Winny.
That's a question for AZZZ.... But version 0.8.1 will support basic theming, so Black Winny will be able to arrange thing like he wants.
Chris-S wrote:I think "Paste Enveloppe Values" should be "Paste Envelope Values"?
Yes indeed; let's say it's a French artifact that will be fixed in 0.8.1.
DrewDale wrote: If you scroll through the pages of this thread, you will also find some links to DX7 sysex patches, also keep visiting here, BlackWinny is creating an ultimate zip of DX7 sounds :hyper: :tu:
Dexed is a true candidate for free vst of the year (up there with OBXD) :D
Haha thanks ! but not for 2014; Dexed 1.0 won't be out this year. That said, OBXD really gets my vote for 2014.
fmr wrote: I was very frustrated, as you can imagine, and I thought to myself: Why didn't I get a message warning me the bank had changes not saved? This is kind of standard behaviour in any piece of software, and it would be great to have that.
Sorry about that... A lot of things will change in 0.8.1 as .syx will be always written on disk when you [STORE] a program so you will never lose your work.
toothnclaw wrote:Dexed should also notify the host that the patch/cart has changed, i.e. that the project state has changed, so that the host can then ask to save the project on exit.

As I wrote in a previous post some time ago.

And yes, this is standard behaviour. Hopefully, it will be implemented soon.
If you change a patch, the VST host is not marking your synth as dirty and needed to be save. All of my plugins works like that... JUCE (it might be the VST spec) doesn't have a force dirty flag... I will have to dig this further to see if it is possible. Again, if you change a knob on the synth; it will be flagged as dirty and needed to be saved and you will have "are you sure" dialog.
fmr wrote:Another request (sorry). Please, make the synth aware of the names, especially of the current loaded cartridge. This is conveniente for quick saving, and also for when we want to load a new, know which one is currently loaded. For exemple, I still didn't manage to listen to all the cartridges that come pre-loaded, since I am always loosing track of what I already load, and end passing over something, or reload something that was already listened - this is annoying as hell.

And having to always pointing to the bank that is currently loaded to save it because the synth isn't aware of its name is also annoying. These are small details that make a huge difference in workflow.
Again, the target 0.8.1 will be based on the effort to bring a usable cartridge manager. All of this will be addressed. This manager will split programs between your working cartridge and available ones... so technically, the limitation will not be 32 but unlimited (let's target 275000 programs :hyper: ).... but the saved .fxp and .syx will be based on 32 programs.

Target date for 0.8.1 will be by the end of the year; I have other projects to do.

Post

asb2m10 wrote:
toothnclaw wrote:Dexed should also notify the host that the patch/cart has changed, i.e. that the project state has changed, so that the host can then ask to save the project on exit.

As I wrote in a previous post some time ago.

And yes, this is standard behaviour. Hopefully, it will be implemented soon.
If you change a patch, the VST host is not marking your synth as dirty and needed to be save. All of my plugins works like that... JUCE (it might be the VST spec) doesn't have a force dirty flag... I will have to dig this further to see if it is possible. Again, if you change a knob on the synth; it will be flagged as dirty and needed to be saved and you will have "are you sure" dialog.
Is it possible?! I think it's obvious. If you change one parameter it is important and the host is notified, but if you change the whole synth state that is deemed not important enough to notify the host? How so, please?

Yes, I know that most hosts can be set up to ask whether to save on exit or not, but that is not the issue here.

The synth should talk to the host - "Hey, my patch/cartridge/browser location* state has changed. My whole state has changed. The project's state has changed. Please recognize this and act accordingly!"

* This should be just like any other parameter and get saved with the project, per instance. Continue from the place you last left off, per instance**. Not like e.g. Native Instruments' browsers, theirs is the wrong way to do it.

** Maybe introduce a parameter that stores the browser path, if the path gets changed, parameter gets changed, the host gets notified, and you browse per instance, not browse on one path for all instances and not always start from the beginning.

I can't believe I have to explain this to a programmer!

Post

Two of the best file browsers I know could teach you a lot about browsing. Please take a look:

http://ghisler.com/
http://zabkat.com/

Post

toothnclaw wrote:
asb2m10 wrote:
toothnclaw wrote:Dexed should also notify the host that the patch/cart has changed, i.e. that the project state has changed, so that the host can then ask to save the project on exit.

As I wrote in a previous post some time ago.

And yes, this is standard behaviour. Hopefully, it will be implemented soon.
If you change a patch, the VST host is not marking your synth as dirty and needed to be save. All of my plugins works like that... JUCE (it might be the VST spec) doesn't have a force dirty flag... I will have to dig this further to see if it is possible. Again, if you change a knob on the synth; it will be flagged as dirty and needed to be saved and you will have "are you sure" dialog.
Is it possible?! I think it's obvious. If you change one parameter it is important and the host is notified, but if you change the whole synth state that is deemed not important enough to notify the host? How so, please?

Yes, I know that most hosts can be set up to ask whether to save on exit or not, but that is not the issue here.

The synth should talk to the host - "Hey, my patch/cartridge/browser location* state has changed. My whole state has changed. The project's state has changed. Please recognize this and act accordingly!"

* This should be just like any other parameter and get saved with the project, per instance. Continue from the place you last left off, per instance**. Not like e.g. Native Instruments' browsers, theirs is the wrong way to do it.

** Maybe introduce a parameter that stores the browser path, if the path gets changed, parameter gets changed, the host gets notified, and you browse per instance, not browse on one path for all instances and not always start from the beginning.

I can't believe I have to explain this to a programmer!
Although I agree with what you wrote, there's no need to be so aggressive. asb2m10 already showed he is competente, and opened to suggestions. You have to keep in mind this is a labour of love, done on free time, therefore, we have to show some understanding, and be patient :wink:
Fernando (FMR)

Post

The new GUI in 0.8.0 looks fantastic. Great job. :) Runs well in Renoise and Tracktion 5, and is amazingly light on the CPU.

Post

asb2m10 wrote:
fmr wrote: I was very frustrated, as you can imagine, and I thought to myself: Why didn't I get a message warning me the bank had changes not saved? This is kind of standard behaviour in any piece of software, and it would be great to have that.
Sorry about that... A lot of things will change in 0.8.1 as .syx will be always written on disk when you [STORE] a program so you will never lose your work.
Although this will solve a problem, it may create others. If you are going to implement this functionality, please write a routine to warn that the patch in question will be overwritten, and therefore lost. Also, please implement simultaneously that functionality of prompting to store in the slot being edited (at least, if we hurry hitting Enter, we would be overwriting the patch that was being edited).

In the current status, that patch overwritten would the Patch 1 - very problematic, IMO.
Last edited by fmr on Thu Oct 30, 2014 12:54 pm, edited 1 time in total.
Fernando (FMR)

Post

fmr wrote:…there's no need to be so aggressive. asb2m10 already showed he is competente, and opened to suggestions. You have to keep in mind this is a labour of love, done on free time, therefore, we have to show some understanding, and be patient :wink:
Exactly. :clap:

/Joachim
If it were easy, anybody could do it!

Post

Spitfire31 wrote:
fmr wrote:…there's no need to be so aggressive. asb2m10 already showed he is competente, and opened to suggestions. You have to keep in mind this is a labour of love, done on free time, therefore, we have to show some understanding, and be patient :wink:
Exactly. :clap:

/Joachim
Sorry if my previous post comes across as aggressive - I absolutely didn't mean to be aggressive, or to create such an impression.

It's probably because I tried to explain in the clearest way possible something that to me seems obvious, important and necessary, but which for asb2m10, by the looks of it, is not obvious, maybe not understood well enough.

Of course, he doesn't have to consider my suggestions, and I could be wrong about everything, who knows? I'll shut up now.

Post

toothnclaw wrote: I'll shut up now.
That's not what I meant or wanted either :) I think your contribution is valued and important.
Fernando (FMR)

Post

When could we see an AU version s'il vous plait ?

Post


Post Reply

Return to “Instruments”