james-trayford
commented
8 months ago Thanks for the suggestions! We hadn't been considering the use case where the user runs the function in the command line outside the the python server - but this does seem like a viable way of using it.
When working with a large data cube, a user will not want to generate an audio file for every pixel the first time they open the data cube, but might already know which region they want to explore. It would be good practise to not letter the user generate too many sound files without a warning anyway?
The listener is actually already rebinning the spaxels to a 'feasible' number (maxn) by default - it finds the rebinning level necessary to achieve < 800 spaxels (hardcoded, by default) when making audio files. Of course, what is a feasible number depends on a user's system, requirements, etc, so it would be good to have the option to set this level. With the browser interface, you should be able to choose the x-y and wavelength range the first time you run (though currently doesn't use raw pixel numbers, instead taking percentiles of the pixel ranges).
I wondered if when running render_soundgrip from the command line, the user could be prompted to choose their values of x1, x2, y1, y2 (in pixel units) and the third dimension (in frequency/wavelength units)
The make_grid function is being run by the server to generate the browser interface (via app.py), so the question is how to open an interactive dialogue when the user wants to run from the command line, and not when run by the server.
I think the best solution is to have a command-line wrapper function which you can run this in the command line. Will open a branch to implement this.
Thinking about feeding more parameters to the make_grid function, we'd already internally discussed switching to a dictionary of parameters (or **kwargs), rather than individual args (@SamYoules)
When working with a large data cube, a user will not want to generate an audio file for every pixel the first time they open the data cube, but might already know which region they want to explore. It would be good practise to not letter the user generate too many sound files without a warning anyway?
I wondered if when running render_soundgrip from the command line, the user could be prompted to choose their values of x1, x2, y1, y2 (in pixel units) and the third dimension (in frequency/wavelength units) - potentially with a suggestion / warning of choosing something sensible that is not too big? Once the javascript version is running in the browser, it is pretty good because one can already visualise the region they want to explore (although a warning for a very large size might still be appropriate)?