Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: fb2k dev (Read 4659 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

fb2k dev

[just few things I wanna know right now]

1. is fb interface system in wa3-like (I mean with message-handler crap)?

2. will be component system powerful enough? (I mean: what can I do without altering exe?)

3. why most stuff is integrated in exe, instead of making separate dlls (so that you can leave only what you need)?

4. why not storing config in %appdata%\foobar? let's beat lazy guyes at nullsoft!

fb2k dev

Reply #1 –
most of stuff is still in the exe because i've been too lazy to separate it (though moving it would be mostly as simple as moving cpp files between projects).
yes, component system is nice, somewhat similar to wa3; it uses wa3-ish "services", also allowing you to define your own "service types" for your needs. i need to add interfaces for getting notifications / controlling playback / etc; right now it's only legally possible to add new inputs, DSPs and readers (there are other service types but they aren't cross-dll-safe yet).
about storing config - i have nice cross-dll-working system to write whatever i want to to foobar2000.cfg, i see no reason to break it.
Microsoft Windows: We can't script here, this is bat country.

fb2k dev

Reply #2 –
Quote
about storing config - i have nice cross-dll-working system to write whatever i want to to foobar2000.cfg, i see no reason to break it.

I think X-Fixer was just wishing that fb2k's config data were stored in a different directory (preferably under %userprofile%\Application Data somewhere), so that the program was multi-user friendly, unlike Winamp.

fb2k dev

Reply #3 –
OK, noted.
Microsoft Windows: We can't script here, this is bat country.

fb2k dev

Reply #4 –
Quote
Quote
about storing config - i have nice cross-dll-working system to write whatever i want to to foobar2000.cfg, i see no reason to break it.

I think X-Fixer was just wishing that fb2k's config data were stored in a different directory (preferably under %userprofile%\Application Data somewhere), so that the program was multi-user friendly, unlike Winamp.

exactly. config in %userprofile% and database in %allusersprofile%. this should free me from Winamp Profiler mess

fb2k dev

Reply #5 –
Quote
yes, component system is nice, somewhat similar to wa3; it uses wa3-ish "services", also allowing you to define your own "service types" for your needs. i need to add interfaces for getting notifications / controlling playback / etc; right now it's only legally possible to add new inputs, DSPs and readers (there are other service types but they aren't cross-dll-safe yet).

Count me as one developer who would love to see something akin to a Winamp v2.x General plugin type, as well as a full set of player controls and ways of getting status to a component.

Basically, if you can take your current user interface, separate it completely from the main part of the application, and make it work as a component DLL, you'd have a truly unique audio player.  Then it would be possible for 3rd parties to add whatever front end UI they want (skinnable, system tray, IR remote control, etc.).

fb2k dev

Reply #6 –
yes, separating "player" from the "core" is the main thing I wanted to suggest. for example, for me the best front-end would be a FAR plug-in (wanted to code it some time ago, using winamp2 plug-ins)

fb2k dev

Reply #7 –
hmm, thats actually a good idea, i'll see what can be done about separating main UI from the exe.
Microsoft Windows: We can't script here, this is bat country.

fb2k dev

Reply #8 –
I also wanted to suggest 2 things about database:

1. instead of storing drive letter in path, store volume guid (or volume id) and maintain lists for different volumes separatelly. this could be very useful for CDs (especially Audio CDs, where most files are named #:\Track##.cda) and network drives, and can increase search speed in this cases.

2. allow storing data of various 'types' like: numbers, strings, text, binary etc.