Reduce number of Max external projects

[tap]

The j~ and j≈ externals are now capable of replacing many of our externals, thus freeing us from maintaining so many projects.

We can use aliases (e.g. j.filter~) to map to (e.g. [j~ filter]) for convenience or backward compatibility. Though compatibility may not be an issue since we just broke everything changing from jcom.* to j.*...

Furthermore, the C++-coded allpass~.model and noise~.model can be envisaged as pointing toward generalised to a j≈.model class wrapper.

[bltzr]

A couple of 2 cents coins :

• I think this [j~ filter] equivalent to [j.filter~] thing is good ! (in particular because the externals can be instantiated in both ways without having to maintain all the j.*.mxo's though, I guess it's good to keep at least the current help files, right ? another thing I'm wondering about : if we do so, then we lose autocompletion support, yes ? If that's the case, maybe that's something to consider... Or is it also managed using the refpages ? And then we would only have to keep the refpages along the maxhelps ?
• Once we have the model wrappers for this classes up and running, I have the impression that the externals are even less useful (because we could just implement these models in compound models such as output~.model), but... • these models should have internal preset, in/out and others automatically included, with the @amenities working (so we can disable some of them depending on the usages...) see #3 for more on this • it would be great to have these models generated automatically when buidling the whole thing - an even better thing would be to have the views and modules also generated by the same script (similarly to what FAUST does when generating pd externals + patchers out of an audio graph) - that doesn't sound overly complicated (for one who masters scripting and the .maxpat's JSON anatomy...) • an even even better thing (but maybe I'm just dreaming...) would be to be able to "compile" a JAG patcher to a j≈ class and .model .... somehow in the way Plugtastic does... but maybe that's for later ?

[lossius]

We'll need a more thorough investigation of the consequences before deciding to do this. I'm not necsessarily convinced that it is a good idea, I'm afraid that it might be convinient for C++ developers of Max externals, but rather inconvinient for the Max user.

Also, a number of issues need to be resolved before this can be done, such as #289 and #290 .

[bltzr]

which inconvenience would it make for the user ? maybe I wasn't so clear, but the idea here is that the syntax remains the same: the user just creates a box with [j.filter~] in it, and it's replaced internally the only downside I can see as of today, is that, when comparing both cases ([j.filter~] and [j.~ filter]), the latter only has 2 inlets for audio signal, whereas the first has 2 extra inlets for the freq and Q parameters - I don't see that as a huge problem, though, as these parameters can be sent with messages into the audio inlets....

[lossius]

j.filter~ is not just a wrapper for one Jamoma DSP unit, but dynamically loads filters depending on it's attributes, so I anyway don't think this object can be replaced by j~.

As a start, I believe that this issue should be considered very low priority. The reason is very simple:

• Do the release of 0.6 depend on this issue? Answer: NO
• Do resolving this issue accelerate the release of 0.6? Answer: NO

IMHO we are spreading our development effors to thin currently, starting to many parallell efforts, and not being good enough at finishing them of. I believe it is important that we make clearer priorities, and then I believe this is one issue to opt out off, at least for the time being.

[bltzr]

all agreed !

Le 3 août 2013 à 18:35, Trond Lossuis notifications@github.com a écrit :

j.filter~ is not just a wrapper for one Jamoma DSP unit, but dynamically loads filters depending on it's attributes, so I anyway don't think this object can be replaced by j~.

As a start, I believe that this issue should be considered very low priority. The reason is very simple:

• Do the release of 0.6 depend on this issue? Answer: NO • Do resolving this issue accelerate the release of 0.6? Answer: NO IMHO we are spreading our development effors to thin currently, starting to many parallell efforts, and not being good enough at finishing thsm of. I believe it is importantthat we make clearer priorities, and then I believe this is one issue to opt out on, at least for the time being.

— Reply to this email directly or view it on GitHub.

[lossius]

This sounds like a milestone, not an issue. Moving to later milsestone for the time being.

[tap]

We discussed these objects at the Florida workshop. There are many downsides to them including the fact that Max cannot provide autocompletion for them or many other expected conveniences.

I think we should keep the objects as they are useful in the cases where a proper wrapper has not been provided, but these objects will never provide the superior experience of a real object.