Re: Feature Request JAMin

On Tue, February 5, 2013 7:27 am, Michiel Broek wrote:
> On 02/04/2013 05:31 PM, Patrick Shirkey wrote:
>>>
>>> I see it like this. A unit for live sound is adjusted once for the
>>> combination of speaker units and amplifiers. Then only minor teaks may
>>> be needed for certain halls, but in most cases it's not necessary.  If
>>> all is adjusted, lock the unit and bury the password. There is a reason
>>> why these DSP's have so few knobs.
>>>
>>> Mastering is different, each song is different and even the same song
>>> can be made different just by tuning Jamin. Jamin does a good job and
>>> works well combined with Ardour.
>>>
>>> I see it as two whole different things even if a lot of processing is
>>> the same.
>>>
>>>>> But if someone would decide to go ahead building a solution for live
>>>>> sound, then I would like to see that happen in a fork of Jamin
>>>>> instead
>>>>> of trying to build all in one application.
>>>>>
>>>> I don't understand why you would request a fork. Jamin hasn't changed
>>>> for
>>>> several years so making some additions is hardly a big deal. If you
>>>> wanted
>>>> to continue using the older interface there could even be a "classic"
>>>> interface for people with that specific need.
>>>>
>>>> Multiple interfaces for multiple uses. Jamin as a mastering tool for
>>>> live
>>>> and post prod. Makes sense to me to have it all in one place. A
>>>> flexible
>>>> and highly customisable solution for audio quality. The sound
>>>> engineers
>>>> best friend on or off stage...
>>> I guess if I would design a software DSP based on Jamin technology, I
>>> still would like it to be so that no one passing by that computer can
>>> change any setting. It's just needed once and is mostly stacked away in
>>> the amp racks too, so it's not in range of the FOH mixer.
>>>
>> In order to achieve something like this with jamin we need a daemon
>> mode.
>> There is one thing in the way of that at the moment. It also affects the
>> "presets" ui mode (-g). Basically the hdeq requires to be realized at
>> least once before everything will work as expected.  The hack is to
>> realize the main window then hide it but in daemon mode we don't want to
>> realize any windows.
>>
>> Jan do you have any tips on how to bypass "realizing" the hdeq. I notice
>> we have the heq_pixmap for offscreen drawable so it looks like we are
>> pretty close already.
>
> Based on these ideas I would suggest to split it in two parts. The
> daemon that does the processing and listens on a network socket for a
> controlling app.
> Build the controller app and let in communicate over the network. Then
> you have the full freedom to install everything on one machine, or run
> headless, or run remote controlled. For local use, use named sockets only.
>

We already have osc support so we might not need a new socket. I think we
can add a flag for remote controlling the daemon via the existing
interface.

I'm not completely across OSC though so if anyone has a suggestion for the
best way to handle it functionally please let me know.

FYI, I have managed to get past the issue of "realizing" the hdeq widget.
Turns out that the update_meters() function was the culprit.

I'm looking at the Daemon mode now and then I will make an update to cvs
for others to  test out...




--
Patrick Shirkey
Boost Hardware Ltd

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb