yoyofr
commented
11 years ago Yes, it really needs to be reworked. I had no time for this and probably wont have more before a couple of weeks/months. If you want to start something you're welcomed.
Rgds Ym
Envoyé de mon iPhone
Le 2 mars 2013 à 22:26, Misty De Meo notifications@github.com a écrit :
I've found the current structure of ModizMusicPlayer to be a really big barrier to contributing new players and improving or upgrading the current players in Modizer. I was looking at refactoring ModizMusicPlayer into a more object-oriented manner. Namely:
- The overall controller code needs to be separated out from classes encapsulating the actual playback libraries themselves. For instance, a lot of controller functionality that's merged in with the players right now (setting the device volume, writing audio buffers to the device, handling compressed archives, etc.) really ought to be handled by a separate class dedicated to that purpose.
- The different playback libraries need to be separated out into separate playback classes with a common external API, which inherit from a generic parent class.
The playback classes could roughly resemble, based on the current API and the API I've been developing for Paula https://github.com/mistydemeo/paula :
Class methods: +(array) extensions - Class variable storing the file extensions the player supports. +(bool) detectsFormats - True if the class can automatically detect formats without using the filename. Some players (uade, xmp) have no canonical extension list. +(bool) canPlay(string file) - Allows a class to specify whether it can play the specified input file, for selecting a player. (This would allow for fallbacks when multiple players support a format, like .mod; currently if Modizer selects a primary player for the format and the plugin rejects it, the file can't be played even if a player which can is available.) Defaults to use the file extension but subclasses can override to use the file's properties, if the player supports this. +(player object) fromFile(string file, int loops, int frequency) - Attempts to instantiate a player object given a file path. I'm assuming here that multiple libraries need loops specified when playback starts.
Instance methods: -(bool) finished -(string) nextSample - returns a rendered sample from the song at the current position and moves the playback position forward -(bool) seek(int time) - seek to the specified location in the song. -(string) getMessage - defaults to an empty string unless subclassed -(string) getTitle -(string) getType - defaults to the file extension unless subclassed -(string) getPlayerName -(int) getSongLength -(int) getCurrentTime -(int) subsongs - defaults to one, counting the primary song -(void) changeSubsong(int number)
At a minimum classes would need to redefine +fromFile and -nextSample in order to function.
Separating out and encapsulating the code like this will make the logic a lot\ more readable, and make Modizer more inviting to contributors like me.
If you agree, I'll start expanding what the classes should look like and begin working on the code.
Further options for refinement could include:
- introduce a songfile class instead of using strings, like I do in Paula, to provide helper methods specific to what Modizer needs.
— Reply to this email directly or view it on GitHubhttps://github.com/yoyofr/modizer/issues/21 .
mistydemeo
I've found the current structure of ModizMusicPlayer to be a really big barrier to contributing new players and improving or upgrading the current players in Modizer. I was looking at refactoring ModizMusicPlayer into a more object-oriented manner. Namely:
The playback classes could roughly resemble, based on the current API and the API I've been developing for Paula:
At a minimum classes would need to redefine +fromFile and -nextSample in order to function.
Separating out and encapsulating the code like this will make the logic a lot more readable, and make Modizer more inviting to contributors like me.
If you agree, I'll start expanding what the classes should look like and begin working on the code.
Further options for refinement could include: