Raw output?

[ning-yu]

I'm looking into the feasibility of using CAVA output to drive a visualizer for Volumio (https://volumio.org). I was envisioning displaying the spectrum analyzer output on the client side, in their browser.

Any chance CAVA can output the FFT results to fifo? We can then push it through a websocket, and let the client draw the spectrum.

Thanks!

[ghost]

@ning-yu I'm preparing to add this feature (1a32055). Do you have any idea how FIFO should be 'formatted'?

[anko]

It sounds like that functionality could be extracted to a separate library ("libmusicvis"?). Programs wanting a different presentation of the bars could import that and render how they will. Similar thinking in #21.

[ghost]

@anko yup, we should make cava only serve as terminal output to libcava(?) @karlstav what do you think? You should create another repo, I can do all the splitting work. This'll be hard as I'm trying to do it now, so I don't promise anything.

[ning-yu]

@CelestialWalrus Would it be possible to format it as JSON? Not sure how cava does it, but I was imagining after each refresh interval to have an output like: {timestamp: [CPU time], spectrum: [[frequency, amplitude], [frequency, amplitude], ...]}

Thanks

[livibetter]

I think the raw output should be sending out the format at cava's most convenient and only single format, we can provide a set of helper tools/scripts for conversion, even a new doc if the scripts ain't too long, for copy-and-pasting would do kinds.

Supporting multiple formats only make things too complicated, not to mention even only consider major/common formats, that's already one too many.

JSON is okay, but if processing using shell script, that's a pain in your waste outlet. I strongly believe the output format is better be shell scripting hackable/easy-parse-able.

For a quick example on the fly in my mind:

<TS> <NUM_FREQ_AMP> <<FREQ> <AMP> ...>\n

Note: the number of the bands is actually quite redundant. If you read that line into Bash array, you already have the number of elements. Even frequencies can be, but better include, I believe, see #15.

If using shell script, you read one line by one line, then another loop to go through frequencies and amplitudes, you can convert it to JSON if you want with a simple shell script.

---

Interestingly, I found this might be providing a way for #21, we can use this raw output to check. But I think having tests on function would be a better road. This for checking output format, it's good, but for FFT result, it's better on the functions.

[ghost]

@livibetter Your post gave me an idea: split cava into client and daemon instead of cava and lib*.

[livibetter]

@CelestialWalrus I can see where you are heading, and I think that might be a good idea, it will make cava be more general and/or reach more potential users. But it should be @karlstav's decision and people to make this happen.

[karlstav]

But would it be more user friendly if you had to run client and daemon separately? How about an optional daemon mode?

For the format i think you would have to include the lower and upper cutoff frequency for each bar. As each bar contains not one frequency, but a set of frequencies with increasing bandwidth for higher frequencies.

@CelestialWalrus Should i create a separate fork? "daemon mode"

[ghost]

@karlstav that would be great. Or makefile option to compile as daemon.

[karlstav]

@CelestialWalrus there is now a "daemon mode" fork. People can work on this to create the daemon mode either as makefile option or run option (or both?). Test it against volumio or (other visualizing clients?) and also find a way to test it against cava itself. Then we can merge the changes in to the master branch at a later point.

But maybe someone else wants to be the owner of this particular fork? I don't know how much time I can spare.

[ghost]

@karlstav I don't know if you can give write permissions to branches, but if yes you can give us three (me, @livibetter, @anko) write access to that branch and also make a testing branch (will make stuff easier, because no pull requests).

[ning-yu]

Daemon mode would be awesome! And frankly, any output format will do. :smiley:

[anko]

@CelestialWalrus AFAIK collaborators can be added only per repo, not per branch.

You can always pull others' changes without them PR-ing. There is little difference between doing that and being in the same repo. Just git remote add the forks of the people whose you care about and git fetch as you would from karlstav's "origin".

If you find yourself doing this often, the hub tool might speed you up.

[livibetter]

@CelestialWalrus thanks for the confidence in me. Although I do think it's a good idea, but I don't believe I will be part of the people who make it happen, or I would already indicate I'll be working on it in my previous comment. Truth is, I've planned quietly step away from here.

@karlstav please don't make me a collaborator. And a word of advice, if you don't have time, I would really hope you either:

1. create an organization and transfer this repository to it, and recruit people can work on it, but make sure first that you have found people that commit to it.
2. transfer to someone else's account who can work on it.

I have seen many projects that sadly die because the owner don't have time for the project, or seemingly intentionally ignore issues and PRs when still active somewhere else on GitHub.

[karlstav]

@livibetter don't worry I'll still be maintaining the "main branch" of cava. And there is still a couple of things I want to try out: ncurses, pulseaudio support, framebuffer graphics. I just don't have time to be working on the daemon mode, so I thought it could be a good idea to put someone else in charge of that part.

But I can always to do the PRs to the daemon mode fork. So just go ahead and work towards that, maybe that would work just as well.

[ghost]

@ning-yu since cava is modular now, you can make your own output method ;-)