Previous Page | Next Page
- by mudlord at 3:20 AM EDT on April 2, 2009
- The day FB2K supported Winamp plugins, hell would have freezed over. Not surprising since the FB2K dev was one of the original Winamp 2 devs.......
That said, I doubt the FB2K dev will allow a GSF component, at least without a major revision of the core for the code to be clean. They have strict standards in regards to how components are developed (ie, they must not use any things GUI wise not documented in thier SDK, etc...)
And then there is the licensing issues with the GPL (and the FB2K people are quite cautious about those)
SmartOne:
http://vbam.svn.sourceforge.net/viewvc/vbam.tar.gz?view=tar
And I am willing to help out if needs be: I have been very bored lately.
edited 3:30 AM EDT April 2, 2009
edited 3:33 AM EDT April 2, 2009
- by DrO at 8:41 AM EDT on April 2, 2009
- Peter was actually a contractor later in the 2.5x+ stage of things from what i remember so not part of the 'original' team. and from what i've seen of the fb2k sdk, it's quite similar incertain ways to the Winamp3/Wasabi sdk but has been properly evolved and implemented in a very compentant manner.
yes winamp's 'api' is poor compared to fb2k but then again when it was attempted to make a better one people revolted (Winamp3 anyone?). there have been improvements to things to be more like the Wasabi interface for newer features but people have a reluctance to implement them (native transcoding in some of the plugins would be nice *shrugs* ). the age of winamp unfortunately hinders doing such things and really would people accept api breaks like happens with fb2k on 0.1 increments - there is always a compromise about such things (as spending too many years working on winamp plugins has taught me...).
to my understanding, fb2k can already cope with sub-songs and realistically, you can have clean code with winamp plugins, it sounds more like the gsf component was an evolutionary thing which often leads to what people deem to be 'poor' code (especially if you're only working against a single audio player to begin with).
both players have their advantages and dis-advantages. the real killer is getting the interest of someone/people to work on making a fb2k component or cleaning up the bad code, etc etc
-daz
- by unknownfile at 8:48 AM EDT on April 2, 2009
- I think fb2k was annoying to work with, because you couldn't use any custom tag editors or any sort of plugin configuration etc. Or maybe I only had scratched the surface a bit.
- by SmartOne at 10:21 PM EDT on April 3, 2009
- Mudlord, I'd appreciate any help, because I've never tackled any real programming projects. Thanks for the link to the source!
I figured the best course of action would be to build the existing in_gsf to make sure that at least worked, which obviously resulted in confusing Linker issues... Still unresolved.
- by kode54 at 10:24 PM EDT on April 4, 2009
- You can use custom tag editors or dialogs in foobar2000 through the context menu API, but it's advised to simply support the built-in tag editor through the metadata NAME=VALUE system. Certain tags can be mapped on read/write for convenience, such as ALBUM<->GAME.
Configuration is also implemented through a custom dialog and configuration variables which are stored on shutdown and restored on startup.
As for foobar2000 only being used by 1% or less of the population, I suppose that is correct, since there were only 417,489 downloads of v0.9.6.4 last week, and that's way less than 1% of the global population.
Porting tip: If making the emulator core reentrant and exitable at any point is too complicated, I would advise using cothreads or fibers to execute the emulator and exit when the audio output buffer is full, rather than using full blown threading.
- by mudlord at 10:34 PM EDT on April 5, 2009
- I think fb2k was annoying to work with, because you couldn't use any custom tag editors or any sort of plugin configuration etc. Or maybe I only had scratched the surface a bit.
You only scratched the surface. It has actually quite a nice SDK.
it's quite similar incertain ways to the Winamp3/Wasabi sdk but has been properly evolved and implemented in a very compentant manner.
And thats what I like about FB2K's system. Much better than what seems to be bolted-on code in Winamp's case.
- by mudlord at 8:07 PM EDT on April 6, 2009
- Got the damn thing to compile.
Had to make some mods to it to get it to compile.
Namely, removing libresample, since thats not needed when using blargg's audio core.
http://www.sendspace.com/file/hawsro
(You need MSVC2008)
All that needs to happen now, is the implementation of Gb_Apu to HA, to get it to the same level as VBA-M (VBA-M uses a 1.8.0 w/ CVS patches core, HA seems to use the 1.7.2 core)
edited 8:08 PM EDT April 6, 2009
- by SmartOne at 12:24 AM EDT on April 7, 2009
- Great!... but it refuses to compile. I'm using Microsoft Visual C++ 2008.
Building the Release version, the Linker wants "C:\Program Files\Microsoft Visual Studio\VC98\lib\msvcrt.lib"
I don't have that, so I change the command line parameter to /NODEFAULTLIB, then it wants libresample.lib, blah blah blah.
Something's wrong.
- foo_gsf by Richter X at 2:02 AM EDT on April 7, 2009
- Would totally love to see that foo_gsf idea, guys. Especially if it had that bandlimited synthesis stuff for the GB Audio, and some selectable interpolation like SNESAmp has (Linear, Cubic, Sinc, etc.)
- by unknownfile at 11:21 AM EDT on April 7, 2009
- HA is indeed based on an older version of VBA
Previous Page | Next Page
Go to Page 0 1 2 3 4
Search this thread
Show all threads
Reply to this thread:
HCS Forum Index
Halley's Comet Software
forum source