Skip to main content

Poll

visualisation API

Call all visualisation services from playback thread with each audio data chunk being sent to output, with timing info.
[ 0 ] (0%)
Implement some kind of centralized latency management.
[ 0 ] (0%)
Create "visualisation manager" service (optional component) which gets calls with data being sent to output, make it process latency and call visualisation services.
[ 21 ] (100%)

Total Members Voted: 71

Topic: visualisation API (Read 4823 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

visualisation API

Post your thoughts here.
note: non-dev posts will be removed, if you don't understand the topic then please don't reply to it

visualisation API

Reply #1
Option 3: the less work for developers, the better

visualisation API

Reply #2
I'm a glutton for punishment, what can I say.

No, I don't know much about visualization issues or design but that is sort of the point of my post.  I like option 3 "service manager" because I assume it will move a lot of the vis complexity into foobar and a client will just need to adhere to the vis service interface callbacks, etc.

For example, for my component I'd be interested in doing a peak meter and would think it nice if I could just get a callback for each data chunk that would provide the information on the levels.

Another hope (i'm pretty sure the service architecture guarantees this) is that there can be more then on vis active at a time.

visualisation API

Reply #3
Looks like I'll have to go for the third option. It was sort of obvious choice to me too, except I didn't really feel like implementing such thing so I decided to post a poll first. Visualisation manager will be fully optional, so no "bloat" - only change in the exe needed to make such thing work with ~0.666 is plugging one simple callback into playback core and making it forward data to some kind of external services.
Yes, multiple visualisations will be supported.

visualisation API

Reply #4
Number 3 seems the most architecturally sound, but number 2 seems fine as well.

visualisation API

Reply #5
I'd rather do 3 than 2 because it's about the same amount of work and "anti-bloatware" people won't have anything to complain about.

visualisation API

Reply #6
Quote
I'd rather do 3 than 2 because it's about the same amount of work and "anti-bloatware" people won't have anything to complain about.

I think the big question is whether or not implementing a centralized latency manager will have any useful application other than visualization. If not, then I think option 3 is best. Does anyone have any ideas as to what Option 2 could be used for other than vis?

Or am I interpreting this wrong and option 3 could be used as option 2 in a pinch?

visualisation API

Reply #7
Looks like #3 is done and kicking (bonus: VIS client code is completely singlethreaded)
Now the next question is, do we need centralized code to extract spectrum info from PCM data ?
I used chunk size of 256 samples, any reasons to change it ?

visualisation API

Reply #8
Quote
Now the next question is, do we need centralized code to extract spectrum info from PCM data ?

No.  You could provide the FFT functions, but I don't think you should actually provide the extracted data.  Seems like the individual plugins should be able to do that for themselves, so they can use a different (faster ?) library if they choose.

Quote
I used chunk size of 256 samples, any reasons to change it ?

Meh.  I don't really see that it matters.

edit:  Actually, I'm almost certain to use the kissfft library, since it's BSD licensed, so I don't really care whether you provide the extracted info or not.

 

visualisation API

Reply #9
... so I ended increasing chunk size to 512 samples (for FFT) and adding spectrum analyzer (using a BSD-licensed FFT library). Test visualisation works OK, I'll try to put 0.7 beta with SDK soon.

 
SimplePortal 1.0.0 RC1 © 2008-2019