Obxd synthesizer

[george]

Obxd sounds great! Where should I put the presets folder so they show up under factory sounds in Logic Pro X?

Thanks.

Use the pkg installer and presets will just show up

[HunterKiller]

In this case, you will have two DLLs (32-bit and 64-bit), so you will have two times the same files.

What, you cant put the 2 DLLs in the same folder??

Anyrate, if someone really needs to have a plugin in 5 different formats, and all of them must be available in both 32bit and 64bit, and each of them must be in a different place on the computer, then maybe, just maybe they are slightly overdoing it. (Personal opinion here.) Still, there are at least 2 different solutions i can think of which would only require 1 set of resources for all scenarios:

1) Make the plugin DLL (or whatever extension a format has) look in its own directory for the presence of a config file containing the (absolute) path to the Skins and Presets folders. If this file is not found, Skins and Presets folders are expected in the plugin dir itself. That way the plugin remains fully portable, nothing of consequence has to be put on the C: drive, (nothing at all if you dont use VST3), and the hardcore pluggers among us can have their 5 different formats in 10 different locations and still only 1 set of resources (in a location of their own choosing) is needed.

2) Make the plugin DLL (or whatever) expect the Skins and Presets folders in its own dir by default. If not present, expect them in MyDocuments, ProgramData, whatever. Plugin still remains fully portable, nothing is being forced onto the C: drive, and those that really need multiple formats in multiple bits in multiple locations can solve their dilemma by putting the Skins and Presets folder into some system folder on the C: drive by choice.

If forced to decide, i would most likely pick Method 1...

Perfect post!

Method 1 is the way it was always done in the old days anyway.

C:\Program Files\Audio Tools\Company Name\Software Name\Data Folders & Settings

Though everything before Company Name shouldn't really matter and should remain user definable.

[george]

I don't see any coherency to use DLL location for presets and skins but I guess we could add such location as secondary place anyways.

[Dasheesh]

Such a pc way of thinking about things. That would totally clog your vst folder.

[george]

Such a pc way of thinking about things. That would totally clog your vst folder.

Caution! Mac vs PC vs Linux drama

[Dasheesh]

Such a pc way of thinking about things. That would totally clog your vst folder.

Caution! Mac vs PC vs Linux drama

Sorry, I had to say something. Thanks for taking up the cause with this little beauty. I think it will pay off for you in the long run.

[george]

You're welcome

[Mutant]

Solution to the preset location drama: Make it optional.


No need to thank me.

[ZeePok]

Agreed.

If you're worried about needing two different skin folders for 32-bit and 64-bit plugin versions, then one could always handle that via a shortcut like the U-he.data folders.

Agreed. Make it that way, and let users decide where to put that Data folder. That way everyone will be happy

 
I use only 32 bit plugins on Windows.

When I can choose I put the dll in D:\VStplugins and the data folder in the same location.

I don't like it when everything is forced to the C: drive .

[orthooo]

Hey guys, I posted this over on the discoDSP wishlist page but thought you might like to know as well. I started to setup the OB-Xd with Novation Automap on my Remote SL controller and it propagated the controls across the layout and I noticed several several features not shown on the Obxd front panel. All of these functions work as long as I use Automap. I haven't found a way to access them otherwise. Maybe they could be added to the panel in an upcoming release?

Lfo sync - on/off
FenvInvert - on/off - invert filter envelope
PwOfs - on/off - Offsets pulse width of osc 2
Selfoscp - on/off - Filter self oscillation on/off
Pwenvbo - both/osc 2 only - Envelope to pulse width osc2/both osc
PwEnv - 0-128 - Envelope to pulse width amount
Envpitch - both/osc 2 only - Envelope to osc2/both osc pitch
LevelDif - not sure what this does

[.jon]

not sure if its been mentioned but clicking a parameter doesnt make that parameter show up at the top of the list in the bitwig device parameters like most vsts.

Was just going to report the same, but from Live- something wrong with the way VST parameters are exposed to host.

Perhaps these bug reports were lost in the pointless folder drama.

Both Bitwig and Live show the last touched parameter for plugins in various places to ease up tasks like automation. This doesn't seem to work with Ob-xd.

[Echoes in the Attic]

Request - 48 note pitch bend option. Then it could be layered for MPE with proper bend automation in but wig. Please please.

[george]

Please use our forum http://www.discodsp.com/forum/ for the feature requests else these would be hard to find in the future

[george]

OB-Xd manual has been translated to Japanese Download at http://www.discodsp.com/manuals/ and http://www.discodsp.com/obxd/ (included with the binary download).

http://www.discodsp.net/pdf/obxd_jp.pdf

[ENV1]

I don't see any coherency to use DLL location for presets and skins but I guess we could add such location as secondary place anyways.

Not sure what you mean by 'coherency', but there certainly are a number of advantages:

- What belongs together is together
- The C: drive doesnt have to be involved
- The synth will remain fully functional even if the OS is completely wiped and redone
- You can simply ZIP up the appdir to make a complete backup of the synth
- You can put the appdir on removable media and use the synth wherever you want
- It doesnt generate any disadvantages for any type of user in any type of scenario

So whether primary or secondary, its a good option to have because as soon as you forcibly involve any system folders on the C: drive no advantage of any sort is being gained whereas all of the above mentioned advantages fly out the window.



As to 'clogging your VST folder'; unless i totally misunderstood the meaning in this context im kinda surprised that anyone would even say that. I always thought it common knowledge that a folder is merely an abstraction which does not exist in that manner on the harddrive, but maybe i was wrong. In any event, its a total non-issue because with respect to the 'efficiency of the filesystem' (or whatever) it doesnt make the least bit of difference whether something is within a particular folder or someplace outside that particular folder. The FS merely checks whatever is present in a volumes ToC so it can represent that data in a orderly fashion to the user, (i.e. organized into folders), but on the harddrive itself there is no such orderliness, bits and pieces of the raw data of ALL folders are scattered about in a random manner, thus the idea that having more files in a particular folder would somehow 'clog' it...well, thats simply not how this works.

(And with respect to host-scanning; i really cant imagine that any host developer could be so careless as to program their plugin-scanner in such a way that it would actually scan everything thats present in the plugin folder. On the contrary, i have very little doubt that they are smart enough to make use of the OSs filetype-filter, so that the scanner only scans for .dll and/or .vst3 files and other types of files arent being involved in the first place. (You know, in the interest of time.))



PS: Any estimate when the externalisation of the UI stuff will be completed?

If its soon i would probably start working on the basic layout over the weekend...