echo~.view: don't use filtergraph~

[tap]

The echo~ module is a common place to start for doing lots of introduction and tests -- and the filtergraph~ object causes lots of headaches including (but not limited to) conundrums when operating with latency over a network.

[lossius]

Is this the disease, or is it just a symptom of it? The general problem is that this will happen with all user interactions that combine more than one parameter into a shared widget. Further down the road it might be that the solution to this would be to see if it's possible to create an approach that is somewhere between j.node and j.parameter_array. If we have three parameters:

/filter/gain
/filter/frequency
/filter/q

could we imagine a new object called j.node_remote that would pass the values of all three of them back and forth in one go, so that we could receive one message in the view that would be distributed tp all three values of filtergraph~, and similarly we could pack all three values from filtergraph~ before passing them to the model in one go.

Thinking of this, it might be that one solution would be to add a j.receive and j.send that connects to the raw filter coefficients a1, 2, b0, b1, b2, and use this to communicate to and from filtergraph~ rather than communicating using gain, freq and q. I'll give that a try.

[lossius]

@tap : I might have come up with a solution to this. Could you please use the filter~ model and view (not echo~) and see if you still are able to reproduce these problems using the bug/1000-filtergraph-in-remote-views branch? If this works now, we just have to clean it up, and apply the same approach everywhere where we embed the filter~ model in other models.

[lossius]

Fixed.