Obxd synthesizer

[fmr]

I think to get rid of that skin mess the skin file should be in one folder with vsti dll.
And Thanks, George, for catching-up the semi-dying project.

You're welcome. Skinning will be enhanced, but we need to add a FXB bank browser first

Not WITH the DLL files please (I hat when developers do this). Just create a folder in Public/Documents (for Windows) and Users/Sharing/Documents (for Mac) and put there all the relevant files (including patches). I would prefer this method, since then all versions of the plug-in (32 and 64-bit), no matter where they are, will share the same files.

[.jon]

Would it be possible to make Obxd save the learnt MIDI mapping, and use it for every new instance?

[george]

Would it be possible to make Obxd save the learnt MIDI mapping, and use it for every new instance?

Possible yes but other things come first

[george]

Not WITH the DLL files please (I hat when developers do this). Just create a folder in Public/Documents (for Windows) and Users/Sharing/Documents (for Mac) and put there all the relevant files (including patches). I would prefer this method, since then all versions of the plug-in (32 and 64-bit), no matter where they are, will share the same files.

Skins will be all external.

[.jon]

Would it be possible to make Obxd save the learnt MIDI mapping, and use it for every new instance?

Possible yes but other things come first

Rgr, thanks for the info!

[ENV1]

I hate it when stuff that belongs together is scattered all over the place, (especially when its being forced onto the C: drive), so i too would vote for a Skins (and Presets) folder within the DLL directory.

(There are those of us who want only the OS and stuff thats close to it (like drivers) on the C: drive, so that the OS partition (i.e. the Operating System) can be deleted/redone/restored/whatever at any time without having to wipe out the applications (or parts thereof) used on that computer as well. Having apps self-contained in one single parent dir helps not only with that particular aspect, it also helps keeping the C: drive small for quick OS backups, makes backing up the apps themselves much easier, (because you dont have to gather everything together from various places), and in many cases (like this) the apps will then be fully portable as well, since none of their parts need to be present in some specific OS-related place on the host computer. (Which means you can put the whole thing on removable media such as flashdrives and take it anywhere you want and it will always work.) And with regard to skin-images and definition files; all you need is relative paths, i.e. no need for environment variables or similar stuff. Same goes for presets.)



That being said, i will start making a from-scratch skin as soon as the externalisation of the UI stuff is completed.

I already have some ideas for a new layout, looking forward to get started.

[HunterKiller]

Nothing worse than sending stuff to My Documents folder, the Documents and Settings folder, the Users folder....
Keep things with the dll, where it has always belonged.

[fmr]

Nothing worse than sending stuff to My Documents folder, the Documents and Settings folder, the Users folder....
Keep things with the dll, where it has always belonged.

In this case, you will have two DLLs (32-bit and 64-bit), so you will have two times the same files. But in the case when you have AU, VST2, VST3, AAX, etc., where will you put the files - one at each directory?

The mess will be instantaneous. That's why developers usually create a DATA folder and put everything there - and just send the proper DLL file for those places (U-He plug-ins work this way). Of course, you can define where this DATA folder goes, but the proper places are Program Data (in Windows), Application Support (in Mac OS X), or then folders in Users/Public (Windows) or Users/Shared (Mac OS X).

I agree that having many files in these directories is not ideal, but having everything together with the DLL is worse, IMO. There is no perfect solution.

[Echoes in the Attic]

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.

[ENV1]

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...

[.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.

[PTV]

I hate it when stuff that belongs together is scattered all over the place, (especially when its being forced onto the C: drive), so i too would vote for a Skins (and Presets) folder within the DLL directory.)

+1

[Funkybot's Evil Twin]

I hate it when stuff that belongs together is scattered all over the place, (especially when its being forced onto the C: drive), so i too would vote for a Skins (and Presets) folder within the DLL directory.)

+1

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.

[fmr]

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

[ontrackp]

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

Thanks.