Re: Feature Request JAMin

On 02/05/2013 12:37 AM, Patrick Shirkey wrote:
> 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, for some ideas about live units, 
http://www.dbxpro.com/en-US/product_families/driverack
The building blocks in Jamin are there, but I think you need a lot of 
configuration options to get to one of these dbx units.


gtx, Michiel.


------------------------------------------------------------------------------
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