Jamoma Max Brokeness

classic Classic list List threaded Threaded
9 messages Options
tap
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Jamoma Max Brokeness

tap
As usual, I guess I know how to efficiently find weaknesses in Jamoma.  I just ran a build.  The first thing I tried to open was the echo~ model help patcher.  Here are my issues:

1.  I'm not sure what to do.

2.  There is no text in this help patcher to help guide me or explain.

3.  In the input module, there is a DSP button that looks like I should click it to start audio but that brings up the DSP status.  There is a button above it that looks less clickable which is what I need to actually click. 
    * Why are these buttons different shapes?  What does this communicate?
    * Do we really need the "DSP" button at all?  
       I suggest "no" -- this is not a standard way of dealing with preferences.
    * The same is true for the output module.

4.  In the input and output modules I can't adjust the gain to go below 0 db.
     Actually, I can if I use the gain know, but the sliders in these modules are complete broken!

5.  The help patcher is not ready to be used.  The input module is in soundfile mode, but with no soundfile loaded.  It should be in a state that gets sound working right away, either by loading a default sound file (e.g. "brushes.aif") or by being set to pink noise (preferably the former).

5b.  The gains should not all be set to linear zero -- again this requires a bunch of input by the user just to make the help patcher function.  At the very least, if the user has to do a bunch of work to get sound out of a help patcher then the steps need to be enumerated as text.

6.  Switching to other tabs the formatting seems messed up.  I didn't bother trying the stuff in those patchers.  Maybe that stuff is in bpatchers and will be easy to fix?  I hope so!

Tim


------------------------------------------------------------------------------

_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
tap
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Jamoma Max Brokeness

tap
An update:

Points 1, 2, 3, and 5, 6 all remain.

Point 4 is fixed -- embarrassingly I had not updated my alias to point to the current version of Jamoma and it was using an old version.

Cheers,
Tim


On Fri, Aug 28, 2015 at 10:34 AM, Timothy Place <[hidden email]> wrote:
As usual, I guess I know how to efficiently find weaknesses in Jamoma.  I just ran a build.  The first thing I tried to open was the echo~ model help patcher.  Here are my issues:

1.  I'm not sure what to do.

2.  There is no text in this help patcher to help guide me or explain.

3.  In the input module, there is a DSP button that looks like I should click it to start audio but that brings up the DSP status.  There is a button above it that looks less clickable which is what I need to actually click. 
    * Why are these buttons different shapes?  What does this communicate?
    * Do we really need the "DSP" button at all?  
       I suggest "no" -- this is not a standard way of dealing with preferences.
    * The same is true for the output module.

4.  In the input and output modules I can't adjust the gain to go below 0 db.
     Actually, I can if I use the gain know, but the sliders in these modules are complete broken!

5.  The help patcher is not ready to be used.  The input module is in soundfile mode, but with no soundfile loaded.  It should be in a state that gets sound working right away, either by loading a default sound file (e.g. "brushes.aif") or by being set to pink noise (preferably the former).

5b.  The gains should not all be set to linear zero -- again this requires a bunch of input by the user just to make the help patcher function.  At the very least, if the user has to do a bunch of work to get sound out of a help patcher then the steps need to be enumerated as text.

6.  Switching to other tabs the formatting seems messed up.  I didn't bother trying the stuff in those patchers.  Maybe that stuff is in bpatchers and will be easy to fix?  I hope so!

Tim



------------------------------------------------------------------------------

_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Jamoma Max Brokeness

Pascal Baltazar-5
On remark about your remarks:

I’m not really sure about what we should do about modules/models help patchers…

IMHO, that’s not where the main interest of Jamoma 1.0 resides… rather in all the externals (j.model and friends…) so I  guess that’s where the most interesting stuff is… and AFAIK where Julien has put most of his work...

IMO, the standard modules are some kind of basic UserLib, they can be useful for pedagogy and such, but are not so interesting as such - at least I never use them myself…

which is another argument for splitting modules and the externals - and just keep one or two well-documented models in order to show how externals are used…

just my opinion, though…

p

Pascal Baltazar
[hidden email]
http://www.baltazars.org

Le 28 août 2015 à 18:04, Timothy Place <[hidden email]> a écrit :

An update:

Points 1, 2, 3, and 5, 6 all remain.

Point 4 is fixed -- embarrassingly I had not updated my alias to point to the current version of Jamoma and it was using an old version.

Cheers,
Tim


On Fri, Aug 28, 2015 at 10:34 AM, Timothy Place <[hidden email]> wrote:
As usual, I guess I know how to efficiently find weaknesses in Jamoma.  I just ran a build.  The first thing I tried to open was the echo~ model help patcher.  Here are my issues:

1.  I'm not sure what to do.

2.  There is no text in this help patcher to help guide me or explain.

3.  In the input module, there is a DSP button that looks like I should click it to start audio but that brings up the DSP status.  There is a button above it that looks less clickable which is what I need to actually click. 
    * Why are these buttons different shapes?  What does this communicate?
    * Do we really need the "DSP" button at all?  
       I suggest "no" -- this is not a standard way of dealing with preferences.
    * The same is true for the output module.

4.  In the input and output modules I can't adjust the gain to go below 0 db.
     Actually, I can if I use the gain know, but the sliders in these modules are complete broken!

5.  The help patcher is not ready to be used.  The input module is in soundfile mode, but with no soundfile loaded.  It should be in a state that gets sound working right away, either by loading a default sound file (e.g. "brushes.aif") or by being set to pink noise (preferably the former).

5b.  The gains should not all be set to linear zero -- again this requires a bunch of input by the user just to make the help patcher function.  At the very least, if the user has to do a bunch of work to get sound out of a help patcher then the steps need to be enumerated as text.

6.  Switching to other tabs the formatting seems messed up.  I didn't bother trying the stuff in those patchers.  Maybe that stuff is in bpatchers and will be easy to fix?  I hope so!

Tim


------------------------------------------------------------------------------
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------

_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
jln
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Jamoma Max Brokeness

jln
Administrator
In reply to this post by tap
Hi Tim,

Indeed, the echo~.model maxhelp is a bit « as is ». As far as I can tell, a lot a maxhelps for model are yet to be updated/cleaned.

Indeed, maxhelp should be ready to be played with. Or at least as ready as possible. I am not fond of patches playing automatically at a defined level, but we must make the patch ready with a final live.gain~ set to -70 for example and a bubble stating to raise the gain.

For particular cases where more elaborated settings are need, then let’s just add a j.cue object with a/few demo cues. Imho, we discussed and tried numerous time to have maxhelps automatically naming models, making presets etc but in the end it hasn’t made it so let’s KISS. If a maxhelp needs a demo cue, then it need a demo cue. Plain and simple.

I’d just remove the audio/presets/etc. tabs and move that information in a dedicated tutorial or example patch about standard features offered with models. As I plan it, we’ll have this example reachable from the « ? » tab.

Finally, I agree with #3. 

Best,
Julien
As usual, I guess I know how to efficiently find weaknesses in Jamoma.  I just ran a build.  The first thing I tried to open was the echo~ model help patcher.  Here are my issues:

1.  I'm not sure what to do.

2.  There is no text in this help patcher to help guide me or explain.

3.  In the input module, there is a DSP button that looks like I should click it to start audio but that brings up the DSP status.  There is a button above it that looks less clickable which is what I need to actually click. 
    * Why are these buttons different shapes?  What does this communicate?
    * Do we really need the "DSP" button at all?  
       I suggest "no" -- this is not a standard way of dealing with preferences.
    * The same is true for the output module.

4.  In the input and output modules I can't adjust the gain to go below 0 db.
     Actually, I can if I use the gain know, but the sliders in these modules are complete broken!

5.  The help patcher is not ready to be used.  The input module is in soundfile mode, but with no soundfile loaded.  It should be in a state that gets sound working right away, either by loading a default sound file (e.g. "brushes.aif") or by being set to pink noise (preferably the former).

5b.  The gains should not all be set to linear zero -- again this requires a bunch of input by the user just to make the help patcher function.  At the very least, if the user has to do a bunch of work to get sound out of a help patcher then the steps need to be enumerated as text.

6.  Switching to other tabs the formatting seems messed up.  I didn't bother trying the stuff in those patchers.  Maybe that stuff is in bpatchers and will be easy to fix?  I hope so!

Tim


------------------------------------------------------------------------------

_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
jln
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Jamoma Max Brokeness

jln
Administrator
In reply to this post by Pascal Baltazar-5
Hi,
On remark about your remarks:

I’m not really sure about what we should do about modules/models help patchers…

IMHO, that’s not where the main interest of Jamoma 1.0 resides… rather in all the externals (j.model and friends…) so I  guess that’s where the most interesting stuff is… and AFAIK where Julien has put most of his work...
Yes, indeed. My personnal roadmap is to get maxhelps (at least modular related ones) and refpages done, then write some tutorials, then update maxhelps for models.

IMO, the standard modules are some kind of basic UserLib, they can be useful for pedagogy and such, but are not so interesting as such - at least I never use them myself…

which is another argument for splitting modules and the externals - and just keep one or two well-documented models in order to show how externals are used…

Yes. I also used few models in the distribution for big projects, but they can still be useful for the reasons you mention. So, provided that they work, I’m fine with having them in the package and see no reason not having them. Also worth noting that a few models are used in some externals maxhelps. During last workshop in Lyon, we thought with with Mathieu not to use models but after working a bit on maxhelps, there is a point when you need to make a basic sound player, then a basic audio fx or movie player to make the help patch or tutorial a bit meaningful. So, at least out of lazyness, I’m fine if I dont have to make lite versions of some existing stuff. :-)

Best,
Julien

just my opinion, though…

p

Pascal Baltazar
[hidden email]
http://www.baltazars.org

Le 28 août 2015 à 18:04, Timothy Place <[hidden email]> a écrit :

An update:

Points 1, 2, 3, and 5, 6 all remain.

Point 4 is fixed -- embarrassingly I had not updated my alias to point to the current version of Jamoma and it was using an old version.

Cheers,
Tim


On Fri, Aug 28, 2015 at 10:34 AM, Timothy Place <[hidden email]> wrote:
As usual, I guess I know how to efficiently find weaknesses in Jamoma.  I just ran a build.  The first thing I tried to open was the echo~ model help patcher.  Here are my issues:

1.  I'm not sure what to do.

2.  There is no text in this help patcher to help guide me or explain.

3.  In the input module, there is a DSP button that looks like I should click it to start audio but that brings up the DSP status.  There is a button above it that looks less clickable which is what I need to actually click. 
    * Why are these buttons different shapes?  What does this communicate?
    * Do we really need the "DSP" button at all?  
       I suggest "no" -- this is not a standard way of dealing with preferences.
    * The same is true for the output module.

4.  In the input and output modules I can't adjust the gain to go below 0 db.
     Actually, I can if I use the gain know, but the sliders in these modules are complete broken!

5.  The help patcher is not ready to be used.  The input module is in soundfile mode, but with no soundfile loaded.  It should be in a state that gets sound working right away, either by loading a default sound file (e.g. "brushes.aif") or by being set to pink noise (preferably the former).

5b.  The gains should not all be set to linear zero -- again this requires a bunch of input by the user just to make the help patcher function.  At the very least, if the user has to do a bunch of work to get sound out of a help patcher then the steps need to be enumerated as text.

6.  Switching to other tabs the formatting seems messed up.  I didn't bother trying the stuff in those patchers.  Maybe that stuff is in bpatchers and will be easy to fix?  I hope so!

Tim


------------------------------------------------------------------------------
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------

_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Jamoma Max Brokeness

Trond Lossius
Administrator
In reply to this post by tap
Hi,

Coming in late here:

1-2: IMHO I believe that it is not realistic to put extensive explanations into each and every model help file. A general screencast to get you going, so that you then can play around and experiment, is probably more useful.

3: This is default look of the live.text in buttob/toggle mode. I agree that they could have looked more intuitive, but that's for Ableton/C74 to address. In general I prefer to use live gui widgets to stay clear of all the changes to GUI objects from one version of Max to the next.

And yes - we need the DSP button. When getting problems with audio platyback in installations, it is so much easier to ask the gallery to click one of these buttons and tell me what they see rather than asking them to go to View Menu and then to Audio Status.

Might be a good idea to add an ezdac~ in local mode to the patch though.

4: I believe 4 and 5b works supposed to. You tested this in the middle of the -96 dB transition.

5: Agree that it should be ready to go. Generally I hate enumerated steps in help patchers, even if the patch is supposed to explain to me what it does.

6: Other tabs should just be deleted. This holds true for most of the model help files.


Best,
Trond
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Jamoma Max Brokeness

Pascal Baltazar-5
Hi !
>
> 1-2: IMHO I believe that it is not realistic to put extensive explanations
> into each and every model help file. A general screencast to get you going,
> so that you then can play around and experiment, is probably more useful.
Very much agreed… Once you’ve understood how a Jamoma module works, there isn’t much more to say than what is really specific to this particular module… which is usually not much, since most modules have very common/well-known functions to anyone with a basic sound/computer music background (which I guess is the situation of most modules users…)
>
> 3: This is default look of the live.text in buttob/toggle mode. I agree that
> they could have looked more intuitive, but that's for Ableton/C74 to
> address. In general I prefer to use live gui widgets to stay clear of all
> the changes to GUI objects from one version of Max to the next.
I just noticed that the rounded corners depend on the button/toggle mode… that’s a bit peculiar design decision but, yes, that entirely belongs to C’74…

Maybe it should be labelled « DSP settings » though - the downside being that this is a quite long label...
>
> And yes - we need the DSP button. When getting problems with audio platyback
> in installations, it is so much easier to ask the gallery to click one of
> these buttons and tell me what they see rather than asking them to go to
> View Menu and then to Audio Status.

My strategy to this kind of problem is to have one area (typically at the topleft) of the patcher dedicated to these functions… but that’s just me...
>
> Might be a good idea to add an ezdac~ in local mode to the patch though.
>
> 5: Agree that it should be ready to go. Generally I hate enumerated steps in
> help patchers, even if the patch is supposed to explain to me what it does.
Agreed…
Could be done with j.cue, as Julien suggested… though there might be some problems if several helps patchers are open (unless we add a j.model to the help patcher itself… which bring some other inconveniences too...  
>
> 6: Other tabs should just be deleted. This holds true for most of the model
> help files.
agreeed !

p

>
>
> Best,
> Trond
>
>
>
> --
> View this message in context: http://jamoma-forums-mailing-lists.3076123.n2.nabble.com/Jamoma-Max-Brokeness-tp7582172p7582251.html
> Sent from the Jamoma Development mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Jamoma-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Jamoma Max Brokeness

Pascal Baltazar-5
In reply to this post by Trond Lossius
Hi Julien !

Thanks for your input, I think there are some very good questions and suggestions here !

I agree that the current j.modular proposal is a bit mixed between being protocol- and application-oriented.
My opinion is that it should be application-oriented.

About the one-does-it-all perspective that you propose, I see the temptation of it, but I am also  quite afraid this might become very uncomfortable to manage… it reminds me of j.namespace’s filters, which are a paramount of user-hostility IMHO…
Basically, what we have here is dealing with objects (local and remote applications), and the best way to do that in Max remains using… well, objects… rather than having some stored/semi hidden table of objects.
For example, you can get the list of all remote applications with the application/list message. But then, what if you want to retrieve their attributes ? 
I’m also wondering what bothers you so much in having to add one object per remote app. Could you be more specific ?

So, my current opinion (which mean it could change) would be to have:
- one object to declare and expose the local application, through different protocols (with different attributes for these protocols..)
- one object to explore a remote application and mirror/observe its namespace structure and activity.

What do you guys think ?

Best,

p


PS: If we are to split j.modular into different externals in the near future, shouldn’t we make some abstractions so patches are not broken after release ?
I remembered we talked about this hence I asked again about it. However, while thinking at it this morning, I wonder whether it is a good design idea or not. But truth is I dont remember at all the reasoning behind the idea of splitting j.modular… So please, a short summary would be helpful if I’m missing something obvious. Anyway, I paste below a little workflow-based brainstorm sketch I did this morning, based on what seems confusing to me as j.modular is at the moment. That is:

- j.modular do two very different things based on the number of arguments. This is hard workflow-wise imho. However, rather than splitting things, maybe we should rather re-work the object and put a focus at the right place and clarify how it inserts itself in the workflow. 

- Currently, it is not clear to me where is that focus. Is it an application-oriented approach ? Is it a protocol-oriented approach ? Of course both are related, but I feel we have room to clarify the focus. Hence my attempt at a « generic » j.network.

- I am not fond of having to create an object in my patch to declare it on the network. Then, do the same on a second patch on a distant application, then add an object in my first patch to declare the remote to my second patch, then add an object in my second patch to declare a remote to my first patch, etc… This surely is explicit but a bit fastidious. + I’m not sure it is good to have to hard-code this in a patch (well, I could actually be sure it is not ;-)

Anyway, here a patch I did while brainstorming. Obviously, object and message names are mainly to get an idea. And not all features are here. Again, just brainstorming.

------------------------------------------------------------------------------

_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
jln
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Jamoma Max Brokeness

jln
Administrator
Hi,


2015-09-05 17:18 GMT+02:00 Pascal Baltazar <[hidden email]>:
[...]
I agree that the current j.modular proposal is a bit mixed between being protocol- and application-oriented.
My opinion is that it should be application-oriented.

Regarding application vs protocol, I vote for application as well. 

The attempt here was another more generic option. That is, a top-level object that manage i/o in a network (or a system) of applications. The focus being the network of application rather than an application itself.
 

About the one-does-it-all perspective that you propose, I see the temptation of it, but I am also  quite afraid this might become very uncomfortable to manage… it reminds me of j.namespace’s filters, which are a paramount of user-hostility IMHO…

Yes, this sketch was clearly inspired by j.namespace which may certainly not be a good idea... In such a case, this could work for me since there are less interdependent options, but still. I agree with your point.

In fact, we could have much simpler messages syntaxe such as : 'application/setup <name> <ip> <port>
 
[...]
For example, you can get the list of all remote applications with the application/list message. But then, what if you want to retrieve their attributes ? 

Not sure I understand. 'application/explore <distant_app>' ?
 
I’m also wondering what bothers you so much in having to add one object per remote app. Could you be more specific ?

The main thing is that's not something I want to patch. Actually, in a lot of cases, that's not something I can even patch while developing my application. For example, if I make a generic spatialization patch, I can decide to make this patch "inter-application-ready". Then, when using my patch for a particular project, I need to set that I'll use it with i-score in that case. But I dont want to modify my patch for that. I'd just send messages through a gui and boom.

Other reasons are really more of a feeling that there's something wrong in that approach, something that kind of breaks the model we have in Max, but I cant put words on this so far. So... 
 
Best,
Julien



------------------------------------------------------------------------------

_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Loading...