Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mattkhan]

I've made this request before (more than once!) in general terms but I have a more concrete requests so thought I'd repost more specifically

a (very) popular subject on avsforum is bass eq, the main thread is about films (https://www.avsforum.com/forum/113-subwoofers-bass-transducers/2995212-bass-eq-filtered-movies.html) and has >12k posts, >600k views and >2.5k films with published filters. This has happened over the last 18months or so. No idea how many people post in there but it's a popular subject for sure

I wrote the app that facilitates this (beqdesigner, docs at https://beqdesigner.readthedocs.io/en/latest/) and it's nice to make it easy to use the commonly used DSP devices. For the most part this means the minidsp and that means producing xml files to load into a minidsp.

Recently another device cropped that is limited in various ways but has a websocket interface, this lets me add the ability to push filters directly into the device and then extend that as means to visualise and manage the entire PEQ bank for that device.

IMV this is a significant gap in MC, one that makes the (very powerful) MC DSP engine a v unpleasant thing to use because it is labour intensive to add/remove filters (so much clicking) and managing different filter sets is v hard to do. There's also zero visualisation apart from trying to use the analyser. All in all, it's not a good experience.

There's also no MCWS support for manipulating PEQ which leads to creative hackery like https://yabb.jriver.com/interact/index.php/topic,124190.0.html (which looks like a really helpful tool but involves the registry so...) & presets don't really work in practice (partly because they are snapshots of the entire dsp setup)

with a few MCWS calls, it becomes easy to make this a problem for 3rd party tools. Minimally MCWS support to GET all the filters and POST back a replacement set would do the job, more fine grained support would probably be generally handy but I'd plan to manage entire filter sets at once). Add this and I'd add this to beqd in no time at all

NB: BEQD UI sample can be found in https://beqdesigner.readthedocs.io/en/latest/ui/add_filter/ (but basically it a bunch of graphs that respond in realtime to filter design and then allow that to be applied to some audio track)

[JimH]

Points for persistence!  We'll take a look.

[Matt]

Could you mock up the MCWS calls and the syntax?  Thanks 😊

[mattkhan]

Great, thanks for looking at this

I think the following would be consistent with the current API

GET MCWS/v1/DSP/PEQ?Zone=12345&ZoneType=ID&Block=1

The zone args are obvious, block refers to PEQ1 or PEQ2. I imagine it would be useful to be able to manipulate the presets in the same way so that could be done via a call like

GET MCWS/v1/DSP/PEQ?Preset=LotsOfBass&Block=1

either way it returns a list of filters where each filter provides the pieces of config currently stored in the registry which, as far as I can see, equates to the options shown in the dialog

e.g.

Code: [Select]

filters: [
    {
        enabled: true,
        type: "mix",
        source: 1,
        destination: 4,
        gain: 0
    },
    {
        enabled: true,
        type: "peaking",
        channels: [1,2,3,4],
        gain: 3.2,
        q: 1.23,
        freq: 40
    }
]

Updating the filters would be done to the same URL but using a PUT or a POST instead and the payload would completely replace whatever is currently set

[mattkhan]

on the subject of being persistent, I do think that it would be much nicer to move towards a more RESTful api which would be like

GET MCWS/v2/zone/<zonename>/DSP/<dsp stage>
GET MCWS/v2/preset/<presetname>/DSP/<dsp stage>

[Hendrik]

Our v1 API is of course XML, and should remain consistent within itself for that, even if its painful.

[mattkhan]

Our v1 API is of course XML, and should remain consistent within itself for that, even if its painful.

I thought you'd made a change recently to let it produce json instead of xml?

either way is fine for this case anyway, json is just much easier to handle in a js app

[Hendrik]

I thought you'd made a change recently to let it produce json instead of xml?

Only for file lists, which aren't strictly a web-service response but serve a playlist file (typically in MPL format, which in itself is XML as well, but .. different, so I just added a new format).

[mattkhan]

Fwiw this feature is now live in a public build which supports the monolith htp-1 (first known device with such an interface).

[rec head]

This would be a very cool feature to add. Easier = Better. I plan on getting the Monoprice HTP-1 but not for a while and I have MC now. Thanks for looking into this.