Re: Feature Request JAMin

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.

gtx, Michiel.


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan