fishBMC

Looks cool, looking forward to it !

--OUTDATED-- --OUTDATED-- --OUTDATED-- --OUTDATED-- --OUTDATED-- --OUTDATED--
You can download fishBMC sources from: fishBMC-3.2.0.tar.gz

So far it's an "experts only" release, but I'll try to make installation more user friendly.

In addon.xml, I can specify library_linux, library_osx, and so on...
BUT: How do I tell the system which bitness to use? Do I have to create two addon packages for 64/32bit?

I have made an Add-On available here: 32bit 64bit
There's also a repo available here

ATTENTION: So far, only Linux 64-bit is tested. If you have success on other platforms, let me know.

idefixs Wrote:I noticed the "SetSetting" function never gets called - is this normal (and if so, what do I do instead to let the user choose parameters) or have I missed something?

Hello Idefixs !

I made the latest Refactor of ProjectM, Milkdrop settings handling. I can help you if you have any question regarding this.

I can tell that the SetSetting() function is get called each time when the visualization starts multiple times going through all settings you have in settings.xml. And of course when any setting is changed in GUI. For example if you check opengl spectrum's code

https://github.com/xbmc/xbmc/blob/master...m.cpp#L354

this function gets called 3 times with *strSetting values "mode", "bar_height", "speed" and their values in "value".

Note that the visualization gets stopped and restarted with screen changes.

There is even the possibility now that the visualization can save its own state like used preset, preset locked status. You can see this for example at Milkdrop code:

https://github.com/xbmc/xbmc/blob/master...C.cpp#L265

If you have any questions regarding this, just ask. Cheers, Alan

Thank you Alan,

I have found out that SetSetting does get called after I return STATUS_NEED_SETTINGS. Works perfectly now.
The other thing you mention is indeed very interesting. Does this mean, I could also have a statically allocated memory area? This would greatly help fishBMC start up faster. As it is now, quite a lot of arithmetic has to be performed for every restart.

idefixs Wrote:I have found out that SetSetting does get called after I return STATUS_NEED_SETTINGS. Works perfectly now.
The other thing you mention is indeed very interesting. Does this mean, I could also have a statically allocated memory area?

No. It only allows introducing some gui hidden settings in settings.xml which can be updated when the vis is terminated. This way when restarting again, these settings get applied through the SetSettings() function. This is useful to keep state of the vis across screens and even across sessions. To hold more data, you could create a file for that. I think keeping a memory area when a plugin is not used, is not so good, but maybe Devs disagree. I am not sure.

I have thought about creating a file for storing the required data. The file would be quite large (up to 80 MB) - i will look into it and see what the performance gain would be.

@idefixs Cool with a new Visualizer, we can never have too many of those!

A couple of remarks...
The 'init' each time the vis (re)starts, how come this is the first viz I've ever seen this in ?
How many built in "Modes" is there ? they seem to repeat pretty often

pike Wrote:The 'init' each time the vis (re)starts, how come this is the first viz I've ever seen this in ?
How many built in "Modes" is there ? they seem to repeat pretty often

Thank you for your feedback!
The answers to those two questions are somewhat interconnected. To run, fishBMC requires quite a large amount of data (in Detail = Extreme we're looking at 4MB per "mode"). Where to get all that data? The fastest way would be to have a statically allocated memory area, which is not currently possible within XBMC. I am looking into the possibility of saving the data to disk, but I doubt this will be a lot faster than the present method of just recalculating everything.
This said, there are currently 20 different vector fields, which could easily be expanded.