Added a few more methods and properties. Have changed the way the runqueryarray works, it now does a standard query. So queries are now of the form:
"type = 0", "artist HAS metall" etc
I will probably put the keyword query method back in under another name.
Have changed the base object to "Application" in keeping with standard automation naming conventions.
Can now create MediaItems by using "LoadItem" and a file name. Or using "GetItem" and a filename to retrieve stuff from the media library.
ATFString can now query for media library items. (rating,playcount etc)
Added basic play,pause etc operations, and a clear method for the playlist.
I have decided that the array mechanism of doing media library queries is ok, as you need to make a copy any way in case another plugin frees your query. But I will probably add another more efficient version of the query that doesnt make a copy, for cases where you want to enumerate the results straight away, and dont need the copy sticking around to process later in an event for example.
With that in mind, I am debating the merits of multi-threading the scripts, as it would require a lot of synchronisation, and I am not sure what is and isnt thread safe in winamp, plus there is the potential for deadlocks.
As the scripts can potentially do anything, it is potentially quite dangerous to make the scripts run in a separate thread to winamp - they would be likely to conflict with other plugins. Thus they will simply run synchronously, just like normal plugins.
Note that this will still allow events and so forth to run, they will just not run simultaneously. Just like normal plugins.
-----------
@Lord Darius. As Ive said numerous times, this is not the interface the plugin will use. As it is obviously still a work in progress, while I am developing it, the first thing I need to do when I fire up winamp is type some test script and test it. This interface allows that. Files arent of any use at the moment as I am constantly changing what I am testing.
The plugin will simply load scripts from files such as:
startup_1.vbs
plscommand_Upload to Ftp.js
etc. The extension will indicate the scripting engine to use. And the plugin will pick them up and run them and add menus etc as appropriate. I will still supply I similar interface to this debug one, for testing scripts, and a means to see what scripts are currently connected for events (running) and let you stop them etc, plus let you load arbitrary scripts etc. Plus supply some kind of console ouput which you can view or hide. It will also have a browser component to it which will let you make use of the scripting inside a browser window in the media library.
But I'll say it again just to be sure. This is not the interface the final plugin will use. It is for testing purposes only, do not draw judgement on it.
As for documentation, you may load the included .tlb in an object browser (any vb/vba/vis studio/ms word type app has one) and you will see all the methods and properties. (done so far, IT IS NOT COMPLETE - testing purposes only, yada yada.).
"type = 0", "artist HAS metall" etc
I will probably put the keyword query method back in under another name.
Have changed the base object to "Application" in keeping with standard automation naming conventions.
Can now create MediaItems by using "LoadItem" and a file name. Or using "GetItem" and a filename to retrieve stuff from the media library.
ATFString can now query for media library items. (rating,playcount etc)
Added basic play,pause etc operations, and a clear method for the playlist.
I have decided that the array mechanism of doing media library queries is ok, as you need to make a copy any way in case another plugin frees your query. But I will probably add another more efficient version of the query that doesnt make a copy, for cases where you want to enumerate the results straight away, and dont need the copy sticking around to process later in an event for example.
With that in mind, I am debating the merits of multi-threading the scripts, as it would require a lot of synchronisation, and I am not sure what is and isnt thread safe in winamp, plus there is the potential for deadlocks.
As the scripts can potentially do anything, it is potentially quite dangerous to make the scripts run in a separate thread to winamp - they would be likely to conflict with other plugins. Thus they will simply run synchronously, just like normal plugins.
Note that this will still allow events and so forth to run, they will just not run simultaneously. Just like normal plugins.
-----------
@Lord Darius. As Ive said numerous times, this is not the interface the plugin will use. As it is obviously still a work in progress, while I am developing it, the first thing I need to do when I fire up winamp is type some test script and test it. This interface allows that. Files arent of any use at the moment as I am constantly changing what I am testing.
The plugin will simply load scripts from files such as:
startup_1.vbs
plscommand_Upload to Ftp.js
etc. The extension will indicate the scripting engine to use. And the plugin will pick them up and run them and add menus etc as appropriate. I will still supply I similar interface to this debug one, for testing scripts, and a means to see what scripts are currently connected for events (running) and let you stop them etc, plus let you load arbitrary scripts etc. Plus supply some kind of console ouput which you can view or hide. It will also have a browser component to it which will let you make use of the scripting inside a browser window in the media library.
But I'll say it again just to be sure. This is not the interface the final plugin will use. It is for testing purposes only, do not draw judgement on it.
As for documentation, you may load the included .tlb in an object browser (any vb/vba/vis studio/ms word type app has one) and you will see all the methods and properties. (done so far, IT IS NOT COMPLETE - testing purposes only, yada yada.).
Comment