Doc Dock !!

Hi all ...i'm just posting this to ask if some like me would like to have a dock option to multi dock thing in ....or several docks ....



Also on thing is killing , is the ability to rename the dongles names (the automap extension is making me crazy in fx bin and in dock pages names .....)

Agood way would be to stick with names that we have in the plugin layout , please cakewalk !! not the registry name

yep 

...Also on thing is killing , is the ability to rename the dongles names (the automap extension is making me crazy in fx bin and in dock pages names ...

 
I wrote a custom plugin manager application which lets me categorize/automap/jbridge/rename plugin dlls to my liking independently for multiple host applications. It doesn't move installed dlls around, instead it uses proxy plugin dlls which simply do nothing but load a dll specified in an equally named txt file. This way, I can have "anyplug (Automap)" available to hosts again as "anyplug". I found this necessary, as renaming automapped dlls don't work, but almost all host preset systems rely on the dll name of the plugin. In cubase for example, you won't find presets in the media bay for "anyplug", if you instantiated "anyplug (Automap)"...
 
I really don't know wether my plugin manager will suit your need, as currently doesn't have an UI, there's no documentation, it is quite technical, and I wrote it for my own needs ;)
 
But, if you like, I might sent you two dlls I wrote, "pluginloader.32.dll" and "pluginloader.64.dll". You could rename these dlls to whatever you like, say "anyplug.dll", and you create a txt-file in the same folder named "anyplug.txt", which contains the path to the dll to be loaded, say "c:\plugins\anyplug (Automap).dll" for example. You'll point sonars plugin scan path to the renamed pluginloader.dlls (and exclude the original dlls from the path) and you will have "anyplug" available to sonar, which instantiates "anyplug (Automap).dll"
 
 

Hi all ...i'm just posting this to ask if some like me would like to have a dock option to multi dock thing in ....or several docks ....

Zo, I'm not sure I understand the question but that never stopped me in the past. I think that the idea of the DOC is to have a single place to put stuff and use tabs to access them. If you need a way to view stuff in an independent way that is what floating views is for.  And don't forget Screen Sets too.

He he, that doesn't make sense to me Mike, would you mind explaining? I remember Dos as a green screen where if I pressed a bunch of buttons at the same time it would print something

There was/is a lot more to DOS than green letters on a black screen.

DOS had a lot docked panels. Eventually after windows were popularized by Mac and Windows, even DOS got windows.

Windows are a revolutionary workflow enhancement.

best regards,
mike

Its funny the doc was in 8.5 too, just not as flexible or as useful. I guess Mike didn't like 8.5 either.

What's bother me is more the waist of space ...in my screenshot exemple , we can have several plugins docked AND visible at the same time ........so you xcan make you're own "channel strip for exemple" .....

One thing i'm thinking about is that the dock fallow (or not , via an option) the selected track !!! so we have and Dock/inspector.....

Tabsel : this sound good ....but i'm not sure i understood everything .....does it touch the plugin ID ?
In short if i make a project with renamed plugins and re open it in another comp , is it gonna load it or are we gonna have this "crazy" prompt for each plugin to let me select the right plugin to load (by the way this is the thing that is killing me for reall!!!!)

I have 2 comp , and bieleive it or not , same plugins don't have the same id !!, i messed with the Registry a little but stoped ....

TabSel

...Also on thing is killing , is the ability to rename the dongles names (the automap extension is making me crazy in fx bin and in dock pages names ...

 
I wrote a custom plugin manager application which lets me categorize/automap/jbridge/rename plugin dlls to my liking independently for multiple host applications. It doesn't move installed dlls around, instead it uses proxy plugin dlls which simply do nothing but load a dll specified in an equally named txt file. This way, I can have "anyplug (Automap)" available to hosts again as "anyplug". I found this necessary, as renaming automapped dlls don't work, but almost all host preset systems rely on the dll name of the plugin. In cubase for example, you won't find presets in the media bay for "anyplug", if you instantiated "anyplug (Automap)"...
 
I really don't know wether my plugin manager will suit your need, as currently doesn't have an UI, there's no documentation, it is quite technical, and I wrote it for my own needs ;)
 
But, if you like, I might sent you two dlls I wrote, "pluginloader.32.dll" and "pluginloader.64.dll". You could rename these dlls to whatever you like, say "anyplug.dll", and you create a txt-file in the same folder named "anyplug.txt", which contains the path to the dll to be loaded, say "c:\plugins\anyplug (Automap).dll" for example. You'll point sonars plugin scan path to the renamed pluginloader.dlls (and exclude the original dlls from the path) and you will have "anyplug" available to sonar, which instantiates "anyplug (Automap).dll"
 
 

is this gonna display anyplug on the plugin gui (and so , the dock) or in the track manager (witch i already did for automapped plugins)


I can find a use also for fabfilter pro plugins that display : fabliter pro (on the the fx bin) and i don't know if it's pro Q or proC or pro L ...ect..

...Tabsel : this sound good ....but i'm not sure i understood everything .....does it touch the plugin ID ? ...

no

...In short if i make a project with renamed plugins and re open it in another comp , is it gonna load
it...

yes
 

...or are we gonna have this "crazy" prompt for each plugin to let me select the right plugin to load (by the way this is the thing that is killing me for reall!!!!)
 

no prompt.
 
say you have your "nativeplugin.dll" automapped. Then you'll have a "nativeplugin (Automap).dll" in the same folder as your "nativeplugin.dll". You can move this "nativeplugin (Automap).dll" around as you like, but you must not rename it for automap to work. In Sonar, you'll have "nativeplugin (Automap)" available, and everywhere there's the (Automap) extension visible, fx bin dock tabs etc...
 
If you now use the pluginloader proxy dll, you simply rename the pluginloader.dll to "nativeplugin.dll" and create a txt.file "nativeplugin.txt", which contains one line specifying the path to the actual "nativeplugin (Automap).dll".
 
So, your "nativeplugin" will be available to sonar (instead of "nativeplugin (Automap)"), but it loads the "nativeplugin (Automap).dll". Simple as that. The pluginloader dll does nothing else than loading a dll, so it doesn't change or alter anything nor does it intercept any VST calls. It is not a "wrapper", or a layer, it doesn't introduce any instabilities, it it simply a dll loading dll...
 
I use every plugin I have automapped and loaded by a pluginloader.dll renamed to the original dll (without the "(Automap)" extension. (My plugin manager app does the creation of dlls/txt-files automatically)
 
 
BTW, there currently is a bug with Automap 4.3 which prevents using two instances of one automapped dll in a session (Sonar X1d expanded crashes, Bug confirmed by Novation). I workaround this by simply running my plugin manager once to have the pluginloaders creating and loading a jBridged version of the automapped dlls. So, currently, I use every plugin automapped and jBridged within Sonar.
 

ok great , need to try that ....can i keep the new dll in the same folder as the old Automap verision (so the original Dll folder of the plugin) ?

one last thing : i understood that when you load the plugin loader verison of the plugin (itch point the real automap) , this is working but when you open old project where this loader were not used .....this will load the automaped old plugin , right ?

Bad news cause i don't feel like moving all my autmaped dll , create a new path ....ect ..

trimph1




This was an earlier version...




According to the site NTFS this was DOS1....

lol this reminds me "Basic" days programming ....

That's not DOS 1, or DOS anything. It actually says what it is on the screen-shot; it's an application that runs *on* DOS 3.0.