Re: Possible modifications to interface

Hi all,

Sorry if I've been incommunicado, I lost access to my old university  
email account some weeks ago, and only just noticed.

I suspect there's some truth to what Patrick says, and I can see a  
simpler UI with less options being popular. However, separating the UI  
would be a pretty big job.

There also an outstanding audio bug in the processing chain, which  
needs to be fixed, I have notes on it, but no linux audio development  
machine at the moment.

- Steve

On 17 Nov 2008, at 03:44, Patrick Shirkey wrote:

> Jack O'Quin wrote:
>> Hi Patrick,
>>
>> I have not seen any responses to your message.  So, here are my
>> (limited) thoughts...
>>
>> On Tue, Nov 4, 2008 at 2:06 AM, Patrick Shirkey
>> <[email protected]> wrote:
>>
>>> I am revisiting Jamin for the first time in a while and have some
>>> thoughts for discussion.
>>>
>>> 1: What do people think of making jamin into a daemon and  
>>> splitting the
>>> interface code off so that the daemon could be run in the  
>>> background and
>>> the interface could be used only when needed.
>>>
>>
>> My initial reaction is that a mastering tool like Jamin is mainly a
>> hands-on interactive session.  Running it in the background as a
>> daemon seems pointless for its primary intended use.  Other uses may
>> appear over time, of course.
>>
>>
>
> I'm thinking of a studio where the compressor is rack mounted and  
> always on.
>
> I'm also wondering if the lack of activity for jamin is partly to do
> with the interface. It might be that we are giving people too much  
> rope?
> I know we have the presets but maybe we still provide too much room  
> for
> error that is putting people off from using it.
>
>
>> As a matter of program architecture, I like the idea of separating  
>> the
>> real-time audio processing from the user interface, which could
>> sometimes run on a separate machine.
>>
>> Changing our existing code base to fit that model would be quite a  
>> lot
>> of work, I believe.  More than I want to take on right now.  I'd
>> consider that a good candidate for a Jamin 2.0 release if someone
>> wants to do that some day.
>>
>
> In terms of the gui code it would be about a weeks work to seperate
> everything out. But in terms of  communicating from the gui to the
> server/daemon I'm not sure the best way to acheive that. Maybe using  
> osc
> as it is already in place?
>
>
>> The existing code seems useful and stable.  I consider that a  
>> success.
>> Some day it will need to evolve, but there does not seem to be much
>> demand for that at the moment.
>>
>>
> I agree. But I think this should not stop the dev process.
>
> I'm wondering if maybe Jamin is too powerful for some users to get  
> into?
> I would have thought that by now every single musician would have it  
> in
> their toolset and there would be a thriving community with requests.
> Maybe it needs a few tweaks to the interface that makes it less scary
> for the casual user to get into?
>
> There is a lot of room for providing completely automated setups and
> hiding the interface away from the user to make it appear as a very
> simple application. I think we have an opportunity to make jamin  
> into a
> program that literally gives the user the best result based on the
> knowledge of the developers rather than asking the user to work it  
> out.
> Of course we keep the interface code for people who have the  
> confidence
> to get into it and tweak things behind the scenes.
>
> I guess what I'm suggesting is to add a very simple panel.
>
> It would just have a few sliders and knobs that when tweaked would do
> everything that a user needed and save a lot of time and confusion.
>>> 2: With the bypass toggles we could resize the interface to make it
>>> smaller if certain parts are not being used. This could be an  
>>> option in
>>> the preferences.
>>>
>>
>> Probably so.  I don't know the UI code well enough to know what that
>> would involve.
>>
>>
> It's a matter of resizing the panels when switches are toggled. It  
> will
> take a little testing to get it nice and clean but it's not a large
> amount of code.
>
> Going on from there it would be possible to use any one of the  
> panels in
> jamin as a stand alone interface. For example if you want a nice gui  
> for
> a parameteric eq  or just some compressors etc...
>
>
> Cheers.
>
>
> -- 
> Patrick Shirkey
> Boost Hardware Ltd.
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Jamin-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jamin-devel


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/