Binding bug?

[Raphael]

Hello there, Thanks you for that new public channel / preset / binding,
Ive spot a little bug… and I have a question also about binding…
Bug : When I create multiple osc output only the first in the row can be switch on/off
I didnot try with the other module… midi etc

Question about uncheck the box that loose the binding…
It seems to me a little bit weird that when I uncheck the box, the configuration of the adress osc or the binding of the midi is lost…
I would like to have the choice to deactivate the communication if I want to but without loosing the configuration…

Thank youuuu :)

[Raphael]

Ho, and I have spot an other one,
The presets, stay there from one patch to the other
And would be possible to set the name of the preset before record it…

[gregsn]

Hello there, Thanks you for that new public channel / preset / binding,
I’ve spot a little bug… and I have a question also about binding…

Thanks for the report. Well spotted. This should be improved with the upcoming preview.

Question about uncheck the box that loose the binding…
It seems to me a little bit weird that when I uncheck the box, the configuration of the address OSC or the binding of the midi is lost…

True, especially interesting for MIDI.
For other bindings, you are often done by just checking, as configuring the column is often all you need.
But: sure, in general, you are right. Would feel good to not lose information. Expect this to happen.

The presets, stay there from one patch to the other

Often this is handy, as you often have patches that relate somehow sitting side-by-side.
A counter-example is a help folder with completely different patches inside, but we figured that typically this behavior is desirable in order to share the presets between related patches.

If you want you can configure the preset folder though.

Sorrily it’s a bit tricky, but it’s doable.

Here we go: Services like the preset service can be configured before they start up.

In the very beginning of the application startup procedure, you can participate and set some configuration keys, that then get read when the services start up.

You do this by implementing IStartup. Here we configure the key Presets:Folder which then gets read by the preset service when it starts up.

And would be possible to set the name of the preset before record it…

What’s your desired workflow?

[Raphael]

Hello @gregsn,
Thanks for the answers…
Suggestion for the the checkbox… maybe the + is not needed ..
And more something like the little pen is empty when its not configured and fill when it is ..
And the the checkBox is just to activate or deactivated the binding…
Using Chataigne a lot, I find really nice to be able to turn on and off certain module (osc, midi, etc) when I need … especially for debbuging purpose…

For the preset, I get the idea to keep the preset visible from one patch to the other but honestly it feel a lot confusing… And look like a bug… Would it be possible to see the difference…
You says “related patch” what does it mean… ?
If I open a help patch on the side quickly to check something … the preset from the help patch is add to my list of preset even if the PublicChannel doesnt match… and they stay there even after I close that helppatch…

I feel like having a shared folder for presets between patch should be a option to configure and not the default behaviour…

For the name of the preset…
When I add a preset the default name is “untitled1/2/3 etc” It could be nice to be able to changed that name before capture the wanted value and then create the preset with my name…
Right now You have to create your “untitled” preset, capture the values and then changed the name in preset panel after…
And Maybe… An other suggestion 😇
To be able to preview your preset when you clic into the title of the preset…

Thank you :)

[gregsn]

thanks for coming back to me.

And the the checkBox is just to activate or deactivated the binding…
Using Chataigne a lot, I find really nice to be able to turn on and off certain module (osc, midi, etc) when I need … especially for debbuging purpose…

sounds like that would be nice to have it on the column header even. Ok it’s added to our feature wish list.

preset visible from one patch to the other

yes ok well. Not ideal. e.g. in the sketch folder I can see your point. Regarding your help patch example: wasn’t able to reproduce. But still: I see your point. We’ll track this.

maybe in the future the presets folder should include the name of the patch (e.g. “presets for MyPatchXY” or “MyPatchXY presets”.

It could be nice to be able to changed that name before capture the wanted value and then create the preset with my name…

Actually you can do this with Capture Advanced. It creates a new preset with the desired name.

Or do you want a button that just creates an empty named preset and doesn’t have the same entries as the previous one. Like just : New, blank, named

We did try several workflows. Maybe try the Advanced button. It could be that it delivers the funtionality you need and we just need to make it more appealing maybe.

To be able to preview your preset when you clic into the title of the preset…

We love the idea. Hold the button to see the preset and on release the old values come back again. playful

[gregsn]

To be able to preview your preset when you clic into the title of the preset…

you saw that:?

[Raphael]

Hey @gregsn
Yes I just saw it! that’s cool!! :)
So there is a way to preview the preset by clicing and holding this eye
and also previewing the preset without trigger it by looking in the dropdown in the little preset columns…

I have more general concern about the UI/UX that is a little bit confusing, I can join some the point name by @yar in the other current post… Public Channels vs Global Channels - #8 by gregsn

But basically, the process of create, edit, recall, preview seems not obvious…

But yes Its already an amazing tool, that need a little bit more love :)

Ps: the drag and drop of the channel in the patch is So coool!!

[gregsn]

But basically, the process of create, edit, recall, preview seems not obvious…

Ok, thanks for the feedback!

Heads-up: Some of the team that designed this part of the UX are currently unavailable. So let’s collect more feedback, and we’ll come back to you in September.

that’s cool!! :)

So coool!!

cool.