Obxd synthesizer

[Mutant]

It's your request, and we have to respect that. But if some developer is going to pick this, there are much more important things to do than trying to pick the pot of gold at the and of the rainbow

Things that are more important than sound ?

Besides, regarding the oscillator drift, either I'm missing something, or there is already some sort of drift. Connect OB-Xd to an oscillator, play the default, and tell me what you see. Unless you are referring to something else.

Default.
Global Spread = 0
Oscillator Detune = 0
Play 1 note.
The oscillators are still slightly detuned, but the amount of detune doesn't change over time, so 0 drift.
Turn off volume on 1 of the oscillators.
Play 2 notes exactly one octave apart.
Almost 0 detune (except the 12 semitones), 0 drift.
*I said almost, because if you hold the 2 notes for VERY long, you will notice a tiny change in the relation of the 2 waves.
Using RS-MET Signal Analyzer (and ears ).

And let's not just start another "faithful emulation" discussion. I guess noone would ever agree about what is a "faithful emulation" and how "faithful" it is (to what, BTW? This synth isn't even emulating ANY Oberheim model in particular. Nobody ever said it was an emulation of OB-X)

OB-X drifts like crazy, not only oscillators.
OBXD nicely captures the filter tracking and the envelope drifts (voice variation section), but not the oscillator drift.

[aciddose]

fmr, while I recognize that you have insisted I'm not welcome here, I'd none the less like to inform you that the feature Mutant is talking about is relatively easy to implement with minimal amounts of work. It should also be (relatively) easy to find someone to do so.

Worst-case it could be implemented with an additional hidden parameter or even a configuration file like obxd_drift.enable that just by existing would initialize new instances with the feature enabled.

[fmr]

Default.
Global Spread = 0
Oscillator Detune = 0
Play 1 note.
The oscillators are still slightly detuned, but the amount of detune doesn't change over time, so 0 drift.

Maybe I'm not understanding you well, but here it does. Maybe it's periodic, but it does. Also, playing a single oscillator and an octave also drifts.

And let's not just start another "faithful emulation" discussion. I guess noone would ever agree about what is a "faithful emulation" and how "faithful" it is (to what, BTW? This synth isn't even emulating ANY Oberheim model in particular. Nobody ever said it was an emulation of OB-X)

OB-X drifts like crazy, not only oscillators.
OBXD nicely captures the filter tracking and the envelope drifts (voice variation section), but not the oscillator drift.

You realize 2Dat never had nor analyzed an OB-X. He just picked schematics, and maybe listened to recording sounds (you may read that in this thread). He was even laughed about when he first came and told that he wanted to do a virtual synth "inspired" by an Oberheim OB-X following that path.

He also clearly stated that he left out the "per voice card" architecture. Someone wanting to make a "faithful emulation" would have to start from this. It would be like programming a new synth from scratch. And for what?

Besides, you already have Op-X Pro II which emulates this "per voice card" architecture.

Picking your example: Are you able to compare two or three OB-X models. Do they drift equal? I believe they don't. I repeat: There are more important things to do than chasing the pot of gold. I guess we can agree on disagree about this. But the majority seem to agree with me too.

[fmr]

fmr, while I recognize that you have insisted I'm not welcome here, I'd none the less like to inform you that the feature Mutant is talking about is relatively easy to implement with minimal amounts of work. It should also be (relatively) easy to find someone to do so.

Worst-case it could be implemented with an additional hidden parameter or even a configuration file like obxd_drift.enable that just by existing would initialize new instances with the feature enabled.

If it's so easy, put your hands on the job. You are free to create a fork of the original, and prove me and all the others that insisted there are other priorites the we are wrong, and Mutant request is the right step to move forward.

Just to clarify: I have nothing against you. You showed in several occasions that you are a knowledgeable guy, and I usually read what you write with genuine interest. I even tried your synth, and although it doesn't interest me that much, I reconginze it has a really good sound, and I'm personally grateful that you shared that for free.

It's just your attitude that sometimes annoy me and others. Maybe you should meditate about that, and do a self exam about your behaviour.

[aciddose]

Edited to remove Xhip alpha version link, if interested in such stuff contact me or check the alpha page. As Xhip really isn't intended to be an "analog emulation" or similar such a feature would never make it in to a final version. The alpha was linked here as a simple proof that given that the overhead of configuring and building the project were already completed, it should indeed take only a handful of minutes to implement such basic functionality due simply to the fact it is so incredibly simple and self-explanatory.

It's a lot of effort for little gain. Implementing a simple tuning = (1.0 + filter(noise)) * ... in Xhip for example took me all of five minutes. Proper per-oscillator scale drift (as opposed to tuning drift which is crap) would take a little bit longer to get right. A config file would be five minutes more. Adding parameterization would take several hours, close to a day. Adding knobs to the GUI would take possibly multiple days. Dealing with the complaints and demands though? Well it just isn't worth it.

The last time I tried to set up a project to compile OBXD I can't honestly remember, but I can tell you it didn't work out. I couldn't even get as far as compiling the example JUCE project and didn't even get started with the OBXD source.

Or did you think I'm refusing to do all this "easy" work (of which there is hardly any to speak of, of course!) because I'm just a total prick? So I'm coming to this thread to "sabotage" it (how exactly ... ?) or something and ruin everyone's day when I'm talking about how difficult the problems are to solve, explaining technical details and defending the programmers while pointing out the lack of respect for the effort they invest and would need to invest to complete such features users deem "easy".

It's open source. Anybody with time to spare can get to work on it themselves and I assure you, the DSP side of this feature is absolutely worthless. It's a couple lines of code at most. How complex it is depends almost entirely upon the complexity "glue code" of incorporating the new feature into the existing OBXD codebase.

[fmr]

It's a lot of effort for little gain. Implementing a simple tuning = (1.0 + filter(noise)) * ... in Xhip for example took me all of five minutes. Proper per-oscillator scale drift (as opposed to tuning drift which is crap) would take a little bit longer to get right. A config file would be five minutes more. Adding parameterization would take several hours, close to a day. Adding knobs to the GUI would take possibly multiple days. Dealing with the complaints and demands though? Well it just isn't worth it. .../...

Or did you think I'm refusing to do all this "easy" work (of which there is hardly any to speak of, of course!) because I'm just a total prick? So I'm coming to this thread to "sabotage" it (how exactly ... ?) or something and ruin everyone's day when I'm talking about how difficult the problems are to solve, explaining technical details and defending the programmers while pointing out the lack of respect for the effort they invest and would need to invest to complete such features users deem "easy".

And here we go again. Seems like you are frustrated that so many people keep talking about OB-Xd, while just a few talk about Xhip.

But explain exactly where and when did people here show "lack of respect for the effort (programmers) invest"? And where and when did any iof the users here stated that any feature that we mentioned as wanted was "easy"? If anyone mentioned the word easy, it was YOU.

But now you started (again) with all the whining about the lack of respect and how much time would be needed, and how we, the "ungrateful" are not "deserving" the effort. Fine, so LEAVE. We don't need you to tell us if something is easy or difficult. 2Dat already clarified what was easy (easier) and what was not (yet, he did the job, from scratch, and never complained about us, quite the opposite). Same happened with George, while he was here.

The only "programmer" that complain about the "lack of respect" and ungratitude is you, Yet, you did nothing for us to be grateful for (regarding OB-Xd) and only came here to criticize and yes, SABOTAGE. And what was easy a couple of posts back, is not so easy, after all.

You now came here recognizing that making the necessary changes (including the GUI) "It's a lot of effort for little gain". It's exactly what I said. So, again, thanks but no thanks. Keep working in Xhip, and leave us alone with our "crap". We owe you NOTHING

[aciddose]

No, I mean for myself.

The effort to even compile the OBXD project is enormous.

The code is easy, I've already written it and it's working fine in my own software: my own closed source software that I'm not giving away for free. Yeah sure, the "Xhip" plug-in is free, but I primarily provide that for my own benefit, not yours or anyone else.

What you fail to understand is that incorporating code into a project like OBXD is 90% of the effort. It requires a familiarity with the code as well as a lot of overhead invested toward compatibility.

In this very thread there has already been discussion about a kick-starter or similar effort to raise funds to hire a developer to implement these features. This was dismissed as "inappropriate" due to the fact you need to raise the capital ahead of time and pay the developer for their time and effort rather than pay for your own benefit in receiving a working product.

If you can't understand how that is disrespectful to developers, then, well

As far as what is "easy" or "hard", you have absolutely no idea how much effort is involved in implementing "a better preset browser", a completely arbitrary and subjective "feature" that remains completely undefined, vs. "per-voice scale tuning drift" which is trivial and concrete.

Did you read the existing posts in this thread?

What are discopDSP bringing to the table by taking over the dev/distribution of this synth?

Time will tell

Translation: "What possible benefit would motivate me to be so foolish as to make promises I may not fulfill?"

Obviously this wasn't necessary to say as what is important is diversion and deflection. The key is to play "tag", when someone tosses you a grenade or rotten fish you simply toss it right back.

Personally I don't like "tit for tat" conversation tag much. I just open fire, preferably by flamethrower where I'm dealing with a rodent.

I see.

Do you think there is any possibility that you could externalize the whole UI definition stuff (i.e. have it all outside the DLL) so that skinmakers can start a skin from scratch with full control over every aspect of it? A good example of how it could be done would be how AudioRealism creates the UI for ADM, where you have a folder containing the images plus a definition file containing the (relative) path to the images as well as their respective sizes and locations on the UI. (Commented ADM definition file attached if you want to take a look. Had to be zipped because for reasons i cannot fathom the forum doesnt allow .txt attachments.)

TR-X - CM.zip

Yes but it will take some extra time as some kind of parser has to be implemented.

Translation: "While that is technically possible it requires a massive amount of work."

Personally I'd say it's a huge waste of time considering the cost vs. benefit. In fact there are existing skinning systems available for JUCE already, but exactly as you say fmr; "from scratch" - why would anyone want to waste time doing that?

I miss dots around the dials. Any chance of adding them?
I would do it myself, but I am too busy at the moment. Thanks

Just make a skin

Translation: "&#%& off."

Well that seems pretty obvious doesn't it? More "polite" deflection.

"I'd like changes to the skin, but I don't have time to do it myself, could you do it?"

"Then do it yourself."

[Aloysius]

Are we there yet?

[aciddose]

https://www.youtube.com/watch?v=YwjIFk2vlrc

[Aloysius]

http://www.youtube.com/watch?v=rpnewIe5IKs

[klinik]

Per oscillator drift.
16 sample and glide LFOs, operated by "amount" and "rate" knobs.
If it increases CPU consumption too much, a button to turn off this feature.

Lack of drift is one of the major things that is missing from OBXD, if OBXD wants to be a faithful emulation of OB-X.

Yes!! +1

[aumordia]

right i'm putting acid trip on ignore...

so here's the problem for me with obxd: i don't have an oberheim. i've never even seen one. in fact i've never touched a "real" synth in my whole life, i've only ever used computers. so i wouldn't trust myself to preserve its sound. plus it seems like a lot of people like the sound as-is and would freak if it changed at all.

obxd might be a candidate for a fork:

branch 1) keep the sound as it is, add some quality-of-life improvements like a preset browser, etc.
branch 2) in addition to the quality-of-life improvements, add new features that could impact the sound.

if there is to be an effort to make obxd an ever-more-faithful emulation of an actual oberheim i think that will require a commitment from somebody who actually has a reference model.

anyway what do folks think about this 2-branch approach? again, i don't know when i'll free up to actually do this, but part of my day-to-day job is organizing these kinds of projects, so perhaps i can grease the skids for some other dev to step in and drive things.

[fmr]

What you fail to understand is that incorporating code into a project like OBXD is 90% of the effort. It requires a familiarity with the code as well as a lot of overhead invested toward compatibility.

I don't see how you can say I fail to understand that, based on what I wrote, but whatever

In this very thread there has already been discussion about a kick-starter or similar effort to raise funds to hire a developer to implement these features. This was dismissed as "inappropriate" due to the fact you need to raise the capital ahead of time and pay the developer for their time and effort rather than pay for your own benefit in receiving a working product.

If you can't understand how that is disrespectful to developers, then, well

I don't remember well how that discussion started and ended, and I don't bother to check that either, but the problem I see in a solution like that is always about "trust". You, as developer, would want top be paid up front, while us, the payers, would want a guarante that we would get what we would be paying for.

If you were going to develop a product, you could open a crowdfunding project, and people who find that interesting ebpugh would (maybe) will to trust you and give you the money in advance. It had been done (not so often) and the results vary.

But, sincerely, if you were the candidate, right now, I would not advance you a penny, because I would not trust you enought for that. But if someone else come here with a proposition like that, and I would find him/her trustful, I would not have any problem in advancing with my share. Anyway, what is usual is that people first do the job, and then ask for money, not the other way.

As far as what is "easy" or "hard", you have absolutely no idea how much effort is involved in implementing "a better preset browser", a completely arbitrary and subjective "feature" that remains completely undefined, vs. "per-voice scale tuning drift" which is trivial and concrete.

You're right, I don't have no idea about «how much effort is involved in implementing "a better preset browser", a completely arbitrary and subjective "feature" that remains completely undefined, vs. "per-voice scale tuning drift"», and I have no problem in admitting it. Yet, besides Mutant (and maybe Layzer) no one else asked for "per-voice scale tuning drift" (I even clearly said I DON'T FEEL THE NEED FOR IT, and I even have real old analogs, so I must have an idea about what I would be missing... or not).

Again, someone came here asking what would people be interested in for a possible new version of OB-Xd. I expressed my wishes, as others did. The majority, as has been expressed multiple times, asked for a better patch browser and manager, and a better implementation of the GUI.

If you think I am completely unaware of how difficult this may be (I am not comparing it to anything else in particular), I give you the example of U-He synths, and the delay in the release of the new Zebra update and RePRO Five, due to the new patch browsing and management system they are implementing. It seems that they, which have paying users waiting for the release, find that at least as important as "the sound" (which is done since a couple of months already). If you and Mutant think that is not important, it's your right. For me, that's what matters the most.

Regarding your quotes, besides the last one (whose guy stated that he wouldn't bother making a minor change in the GUI because "he had no time" but thinks others should find the time to fulfill his request), I don't see how anyone showed any lack of respect. And, again, George didn't complain.

And you have absolutely no right to complain about anything in that regard whatsoever, because your contribution to the job, so far, was frightening any possible candidate, preventing them to even think about it. What you have to gain with that attitude is something only you can say. But that you have been nothing but a prick, that's a fact.

About your precious "close code", keep it. I am not missing anything in that regard.

[fmr]

obxd might be a candidate for a fork:

branch 1) keep the sound as it is, add some quality-of-life improvements like a preset browser, etc.
branch 2) in addition to the quality-of-life improvements, add new features that could impact the sound.

I put my vote on option 1, clearly

And I already express you my regards for considering it

[aciddose]

About your precious "close code", keep it. I am not missing anything in that regard.

You seem to be missing a preset browser, although since you don't define what that even means there is no way to be certain.