Free-Plugin site for SCOPE

[ehasting]

Can anyone here make this post sticky?

[dante]

looks great. Awesome infact. Only thing thats sprung to mind was this.
would be cool to have some sort of tutorial page on how to make plug ins on the sdk?

I started one 1n ScopeRise January. So far its mainly just links to other resources obtainable here, so any more additions welcome:

http://www.hitfoundry.com/issue_13/sdk_mast.htm

Can anyone here make this post sticky?

Only John C could I imagine. And if he did that, I'd want one for my thread requesting ScopeRise subscribers Everytime I bounce that (once every month or two) I get a couple of new subscribers.

[asktoby]

Good initiative. This site will be very useful.

My vote would be for local mirroring of the files; Otherwise, broken links will be problematic later in life.

I've added votes and comments for the devices I know about and will continue to check back as you add more.

[guppy]

For those who are interested, I've collected 99% of the devices in one zip folder, everything is classified with care.
You can just install them in the same order they appear, and their dsp files when there are some:
free_devices (560Mo)
You will see that I put a few more old plugins than described by Mr Arkadin, but I can't remember which ones
I tried to complete the dead links when I had the device in stock, and maybe add 1 or 2 legacy synths.
Have a look !

[guppy]

And a folder with non-classified devices, i haven't got the time to classify them, as I don't have time to see what they do.
non-classified devices (95Mo).
Use them carefuly !

[netguyjoel]

Holy shit. I was wonderinf if and when someone was going to do this...Thank you all so much for the all that work!

Has anyone done the same thing with Modular as well?

[guppy]

Thanks !
It was not easy to choose author or functionality, I made a something in the middle: as I can say who made it, I tried to put them by author name..but not every time
And sometimes I didn't know what they do, or when they were more numerous, author name classification was easier.
I added a modular folder into the zip, but as I don't use it by now, I spent less time on it.

[Eanna]

Thank you very much Guppy. I've tried to do this twice before, never made it past 50% complete...

Did you script any part of it? I've a raw script that uses 7z, point it at a directory of rars and zips, and it'll extract the files, put files of particular filetypes into a directory structure similar to the Scope install.
It's useful, but it does not classify devices!

I was hooking up a google lookup for each archive name (the zip/rar) in the input dir to present the first hit from planetz in a browser, and allow you add metadata about the classification and author interactively, before it extracted the files from the archive. Never finished that...

With your good work, maybe it's not so important now?

We should look to specifying a file structure to be bundled with each archive, maybe an xml file, with metadata about the device contents. Something like this:

Code: Select all

<device name="Sharc Loop Sequencer">
  <metadata>
    <version>0.6b</version>
    <description>LOOP is a 16-step MIDI sequencer capable of Note, Pitch bend, Control change, Channel Aftertouch, Poly Aftertouch and Program Change message output per step. 32 patterns can be stored and recalled either from the device panel or via incoming MIDI notes.</description>
    <classification>Midi</classification>
    <author>sharc</author>
    <site>http://forums.planetz.com/viewtopic.php?f=16&t=28778</site>
    <screenshots>
       <url>http://forums.planetz.com/download/file.php?id=9543</url>
    </screenshots>
    <demo-tracks>
       <url>http://wherever.com/Loop/coolness.mp3</url>
       <url>http://wherever.com/Loop/thebiz.mp3</url>
    </demo-tracks>
  </metadata>
  <files>
    <device>Loop v0_6b.dev</dev>
    <preset>Loop v0_6b.pre</preset>
    <manual>Loop0.6.pdf</manual>
    ...
  </files>
<device>

We should provide an enumeration of the values that the <classification> element can take, so we might think of an xsd schema to accompany the file.
We could add support for multiple languages by allowing i18n on the <description> element.

This device-description file would be present in the root of each zip/rar archive.
Let's call it device-description.xml.

A little program that presented these fields (with a drop-down for the classification) to save the bother of typing the XML would work too, to be made available to the device authors... and this could be augmented with a fileselector for selecting the .dev, .oxe files etc. for inclusion in the archive. You'd fire up the application, fill out the fields, choose the files, and it'd spit out a zip wrapping it all up together.

It'd be handy enough to do up a bit of XSL to transform device-description.xml to a HTML page.
This could be leveraged by psy-works.net, for device descriptions... and to provide an overview page of the devices you have installed locally on your own system.

This metadata could be done up for the core devices supplied by Sonic Core too. And use the metadata to improve the S|C shop. Anyone handy at websites could easily jazz up the shop, once you have the content!

This strategy solves an age-old problem when I was a VST-only user (before Scope) - what bloody VSTs had I installed?
Same problem applies to Scope, and since there's multiple files in multiple dirs, it's even a bit tougher than VSTs to track...

With such a file structure, a standard 'installer' script (similar to the one I was working on myself) could easily be authored, with no guesswork or legwork, to archive your Scope install, unwrap the zip archive containing the device, and put the files in the right places in under your Scope install dir...

Wonder if something like this will be part of Scope 6?

Are we interested lads? It's a neat little task... I'd be happy to take it on.
I can generate a first-cut of the metadata based on the directory structures in your zips Guppy. Or maybe ehasting, you could share the applicable content from your psy-works.net site?

Anyone else got some ideas to contribute here?

Cheers, Eanna

[jksuperstar]

Maybe using Yum, RPM, etc to make a package management repository somewhere?

Handling dependencies is important for modular patches/devices. (since there are many third party modules available).

Having a package management system is nice, because someone can always save the list of devices they've installed, then do a complete reinstall, and get all devices installed and back in order in no time.

[Eanna]

Modular patches and dependency tracking, aye...

Is there a way to introspect on a Modular Patch file and get a list of Modules employed by the Patch?
The .mdl file for a Modular patch is binary - does anyone know if there is something out there that can report on the modules used in that .mdl?
Maybe something in the SDK?

Does anyone have access to the specs for a .mdl file?

Don't think that devices need dependency tracking? Any one device should be whole and self contained... And I think that all available devices are done up that way (?).

[jksuperstar]

Handling Modular Patches could be a separate thing, anyways.

[Eanna]

Yep.

Maybe S|C will provide the file format spec for .mdl files. We just need the Module ID's... A little utility to spit out the list of modules, that's all we'd need to handle Modular patches...

But I won't design myself out of the notion of dependency tracking...

[netguyjoel]

I'm wondering if anyone has collected all of the free Moular Modules into a directory structure, to import into Scope?

[ehasting]

If the idea shall survive, it needs to be tied up with a scope free app-store kind of web page.
Allowing for auto install, by clicking the install button. Like an URL helper into the install tool.

The installer tool should like apt/yum, track index of local installs.

The idea is great, If we can connect it to user interface and solutions for the "not so handy with pc" people.

I can help with coding, repos storage, etc. If needed.

[Eanna]

I'm a good desktop and backend programmer.
I know Java, am handy with a DB, and know enough C# and Java Swing for desktop frontend.
But I don't know much about modern Web frontends.

Do you have the rights to install stuff on psy-works.net host? Like a DB and an App Server? I see psy-works.net is some PHP-based app framework - which one? Does your PHP framework allow for User Logins?

Yes, I can see it something similiar to the Native Instruments or Waves kind of installer - you install the Installer, and that reaches out to the web-based repository.
Or, your idea is nice, URL Helper idea, initiating the Install action from a Web link.
We really need to prove how easy it is to get the keys for paid-for devices generated online too. I understand that you need proof of purchase... One for another day....

For now tho, just the XML metadata and the desktop app to extract stuff is the first place to start...

I'll do up some designs / early prototypes in the coming days..

Anyone else with additional ideas, please post them here for now...

Cheers, Eanna

[guppy]

There's an old list of plugin into the non classified plugin, that we can see we lost a lot of devices since the early versions of scope.
I've looked at the 2nd folder yesterday, and saw that it wais not very useful, and there's a lot of redondances.

In my humble opinion, i don't like the idea of an online app to do the job.
It would be much better to have local installer that could be maintained up to date as a package, or an iso, with a graphical interface to help users to install, desinstall, or add plugins into the scope folder.
This iso or zip could be manage into the sonic core website and other places.
I say that because a lot of website which supported scope devices have already disappear An online app should be sure to be maintain over years.

I'm sure of veteran user could classify the devices better than me, I tried to do the best. If I knew exactly what each device do, I could classify them only by function, which I think is much more clear.
For example, Derknott devices were so numerous , and their name didn't always talk to me

edit: I've read completly what Eanna said, and I understand it's a local app, so it's very nice !

[ehasting]

Local app is nice, and the online part is not out-of-sync with the idea.

Local app/repository will do installation and management. However the web-site/online repo. is where the "new" plugins are stored.
Whatever you do of local, we need a place where new people can download their new packages and get it installed. And then there is the fact that not everybody wants to install all. People should be able to pick them self. Next point is that we need some presentation of the plugins with included sound examples. keeping a local "app-store" software working also requires updates do work with coming windows versions, os x (which is rumored to be supported by scope).

Keeping presentation and repo. online and installation managment local is what makes sense.
i have had the psy-works.net domain/web space since 2002, and the costs i have around hosting it is marginal to me. I cant see why i should not have the pay-works.net domain in 2022 .

However there is not chance in the ocean that sonic-core will be a part of this, however they might help us with information to realize it.
Rgs
Egil

[Eanna]

Hi, yes all good.

Re. multi-OS support (incl. OS-X) - a Java desktop app will work on both Mac and PC... And I know Java far better than I know C#, so I would definitely turn a Java Swing app around alot faster, and I would be confident that I would implement a maintainable app. We can look to port it to other native variants if needs be... But to deploy Java to the Desktop has improved alot over the years - the Java Runtime is a quite a large one-off download, but with modern broadband web connections, it's not the headache it used to be.

So I'll implement the prototype in Java, unless someone begs otherwise.

As for Remote or Local repositories - I understand the issues, and so, I will support both. The Repository of categorised Zips will be a datastructure - whether that datastructure is hosted remotely or locally, that will be an option in the installer for the user to choose. This will enable Scope PCs not connected to the web to access a local directory that contains (a subset of) the zips hosted on psy-works.net. An accompanying Repository Management desktop app will allow you choose Zips from the remote repository to populate the local repository. Version 1 will not have this facility programmed-up, as I'm guessing the majority of Scope PCs are web-connected these days. Again tho, we have to come up with a file format for the Repository datastructure, so I won't design myself into a corner with respect to the specification of the location of the repository URL (a http URL to psy-works.net or a file URL to a local dir).

As for the 'hardest part' of this, the categorisation of what each device is, ehasting maybe we should allow the current psy-works.net site to accommodate the Category drop down. This would allow us to get that 'last piece of the jigsaw' for the device-description.xml file. We would invite Scope users, especially the experienced Scope heads, to categorise each device directly on psy-works.net. Ideally, we would allow an 'upload' function or link to a Soundcloud URL for the demo tracks too, and a screenshot if one isn't readily available...

I'm also interested what directory structure Scope users find useful for storing devices... The categorisation of devices in the Scope directory is the place to start. But do people like to put the device developer's name in the directory structure too? Or have finer-grained device sub-categories?
I'll knock up a little script that lists the devices in a user's Scope dir, and I'll invite Scope users to PM me their installed device listings. I presume that people accept defaults for the Scope installation dir at install time? Does an installation of Scope for Xite users create a different installation root?

ehasting, the device ratings are inserted into a DB table somewhere? It would be very useful if I could leverage any existing database schema you have backing up psy-works.net at the moment... I guess that if there's a DB, it'll be a MySQL schema... What are the chances of your doing an export of the schema and making that available to me? I may be able to augment it to capture the repository metadata... And also, do you know if your PHP web framework supports user logins? Not so important I guess, since what you have installed will be stored locally, as a config file that the local Installer app uses...

Thanks, Eanna

[ehasting]

Hello,

Categories should be harmonized with the psy-works. Whatever we come up with we will change the psy-works page to reflect that.

The psy-works.net is running wordpress which is a php framework running with a mysql backend. the rating is a 3rd party plugin. but if we are going to create something that we can use together with your tool i think i will write my own plugin with my own database structure. The reason is that i cant guarantee for the future developement of the plugin when is 3rd party like that. And also changes to the plugin might destroy our application.

Whatever you come up with of stucture and framework i can probably create to reflect on the web-page. We will still be using php and mysql for the web frontend, since its easy portable to any web-hotel, and very easy to maintenance and code in.

i would like some kind of app-store apporache, where when people have installed a plugin. the plugin has a path to get updates (online), if any developers makes updates its easy for the user to update their plugins.

local application could be tracking everything using a sqllite kind of database, by doing that we can create same structure on the online web page aswell as the local database, not having to design double structures. however installation packages are a selfcontained (zip?) archive using some kind of file descriptor like the xml example.

if user is not connected to internet he can still update his packages with the same installation package.

That means you can create a GUI, with a self containted package system which dont require internet, but a supporting architecture are available online aswell. That also means that if the web-page goes away which people on this forum have predicted . the tools will still work as long as plugins are packaged in the described structure using the xml descriptor file.

My suggestion on how to package the plugin:
There is a few way to package the installation package. i would suggest a one level package, with an xml file, where the xml file describes relative where all the files should be copied, and also what md5 hash the file should have (for corruption validation). Scope installation path is relative and can be detected or edited by the user from the gui program.

on installation of a plugin that does not exist, he can by him self select where he wants it, or of he want the default. If the plugin already exist on the system it will be upgraded or downgraded. Both should be possible.

DevicePackageFileName.zip
|- device.xml
|- something.dev
|- something.pre
|- something.dll

Code: Select all

--- Content for device.xml
<device name="Sharc Loop Sequencer">
  <metadata>
    <version>0.6b</version>
    <description>LOOP is a 16-step MIDI sequencer capable of Note, Pitch bend, Control change, Channel Aftertouch, Poly Aftertouch and Program Change message output per step. 32 patterns can be stored and recalled either from the device panel or via incoming MIDI notes.</description>
    <classification>Midi</classification>
    <author>sharc</author>
    <site>http://forums.planetz.com/viewtopic.php?f=16&t=28778</site>
    <screenshots>
       <url>/sharc/Loop/screenshot1.png</url>
    </screenshots>
    <demo-tracks>
       <url>/sharc/Loop/coolness.mp3</url>
       <url>/sharc/Loop/thebiz.mp3</url>
    </demo-tracks>
  </metadata>
  <files>
    <file index="1">
          <name>Loop v0_6b.dev</name>
          <type>device</type>
          <hash>69b804eb697e9899a8100536fac187df</hash>
          <version>0.6b</version>
   </file>
    <file index="2">
          <name>Loop v0_6b.pre</name>
          <type>preset</type>
          <hash>h4b80deb697e9899a8100536fac187df</hash>
          <version>0.6b</version>
   </file>
    <file index="3">
          <name>Sharc_Loop.pdf</name>
          <type>pdf</type>
          <hash>ffb804eb697e9899a8100536fac187df</hash>
          <version>0.3</version>
   </file>
  </files>
<device>

The only change i would suggest is down in the Files structure to allow for more flexibility in the future, and also to include the hash.

Regarding links, perhaps it all should be realtive path, so the application can instead include repo. address, with a defined structure, so if one server goes down, its easy to change. If we have in mind a structure like they do with apt and yum, its also easy to mirror if needed by others. And i can host one copy of the repo online on psy-works., and one on my home server. I can probably also host a version on a third server.

Btw i also know Java quiet well so i can be helping out if nessesary.

Eanna, do you have some kind of chat service (gtalk?)? should we start up a github perhaps?

[Mr Arkadin]

I'm sure of veteran user could classify the devices better than me, I tried to do the best. If I knew exactly what each device do, I could classify them only by function, which I think is much more clear.
For example, Derknott devices were so numerous , and their name didn't always talk to me

I classified a lot of those devices in this thread in some detail.

Personally I prefer to manually place these devices where I want to as I put them away from the stndard installation which makes it easier to see what I've got and I can be wary of the legacy devices.