search

ircam-ismm / catart-mubu

MuBu based version of CataRT
29 stars 3 forks source link

finalise camu.analysis #116

Open diemoschwarz opened 4 months ago

diemoschwarz commented 4 months ago
diemoschwarz commented 4 months ago

@einbond , @christophertrapani: can you please check with branch wip-analysis the following things:

  1. Do the camu.process.* still work for you? There's one change: I had to replace the [r #1] with [r #1-process] to avoid Max errors.
  2. try out camu.analysis
  3. We're hitting a contradiction: the umenu inside camu.analysis has all existing camu.process.* variants listed, the outside umenu should not. maybe we need to get rid of the inside umenu completely, or copy it from the outside one?
einbond commented 4 months ago

@diemoschwarz Sorry I am getting a little lost here trying to keep track of multiple branches, but I think the camu.process.* still work for me. However, I agree these menus are getting terribly out-of-sync: in tutorial 5a analysis there are two older versions of the umenus that do not correspond to the most recent camu.analysis. I would find it pretty inconvenient to get ride of the inside umenu. Would it be possible to populate the umenus dynamically using @autopopulate 1 and looking for a subdirectory containing the modules?

diemoschwarz commented 4 months ago

@einbond — the rationale is that different top level patches should be able to offer different analysis choices. (The mfcc-pca one, for example, should not offer descr.) We could also fill the internal umenu from the external one.

einbond commented 4 months ago

@einbond — the rationale is that different top level patches should be able to offer different analysis choices. (The mfcc-pca one, for example, should not offer descr.) We could also fill the internal umenu from the external one.

Okay, I see, yes, let's fill the internal menu from the external one. Or feel free to overrule me and just delete the internal menu. :)

christophertrapani commented 4 months ago

For me, processes still work. And I would be in favor of keeping both internal / external menus if we can find some way to correlate them dynamically.

On Wed, Apr 17, 2024 at 9:55 AM diemo @.***> wrote:

@einbond https://github.com/einbond , @christophertrapani https://github.com/christophertrapani: can you please check with branch wip-analysis the following things:

  1. Do the camu.process.* still work for you? There's one change: I had to replace the [r #1 https://github.com/ircam-ismm/catart-mubu/issues/1] with [r #1 https://github.com/ircam-ismm/catart-mubu/issues/1-process] to avoid Max errors.
  2. We're hitting a contradiction: the umenu inside camu.analysis has all existing camu.process.* variants listed, the outside umenu should not. maybe we need to get rid of the inside umenu completely, or copy it from the outside one?

— Reply to this email directly, view it on GitHub https://github.com/ircam-ismm/catart-mubu/issues/116#issuecomment-2061457500, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIRYDC26A52SFEDLRRYQV7LY52EOXAVCNFSM6AAAAABGJMRSC6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRRGQ2TONJQGA . You are receiving this because you were mentioned.Message ID: @.***>

diemoschwarz commented 4 months ago

I agree that the internal menu is useful. Here is how it could be sync'ed to the external one, let's see which one is the least hassle (e.g. requiring specific connections b/w umenu and camu.analysis):

christophertrapani commented 4 months ago

Something my students pointed out: the structure of the patches inside camu.analysis makes it a little difficult to easily store / recall segmentation parameters. Maybe we can think about integrating a pattr / snapshot system that allows this more easily?

On Fri, Apr 19, 2024 at 3:36 AM diemo @.***> wrote:

I agree that the internal menu is useful. Here is how it could be sync'ed to the external one, let's see which one is the least hassle (e.g. requiring specific connections b/w umenu and camu.analysis):

  • set the internal menu by argument/message (by default everything is available, or nothing?)
  • query the external menu by cycling through items (because we don't want the dump output to be connected mandatorily)
  • some nifty pattr/attr querying of the external menu
  • use camu.analysis in a bpatcher just showing the internal menu, add an "open" button (this would get rid of the external menu, but requires giving the allowed processes as argument)
  • anything else?

— Reply to this email directly, view it on GitHub https://github.com/ircam-ismm/catart-mubu/issues/116#issuecomment-2066099868, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIRYDC7RJFV7Z7F5A3LIKJ3Y6DJPDAVCNFSM6AAAAABGJMRSC6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRWGA4TSOBWHA . You are receiving this because you were mentioned.Message ID: @.***>

einbond commented 4 months ago

Hello Chris, this is supposed to be built into each analysis module (camu.process.* — see screenshot). Each relevant attribute of mubu.process or pipo is listed in the pattr objects on the right. Of course if the segmentation module changes, then the attributes may change, but if the attributes are available they will be recalled. Do you think there needs to be something more or different?

einbond commented 4 months ago

Hello Chris, this is supposed to be built into each analysis module (camu.process.* — see screenshot). Each relevant attribute of mubu.process or pipo is listed in the pattr objects on the right. Of course if the segmentation module changes, then the attributes may change, but if the attributes are available they will be recalled. Do you think there needs to be something more or different? 

Screenshot 2024-04-29 at 15 23 40
christophertrapani commented 4 months ago

Some things to consider:

Just to give you an example from teaching: With students who are unfamiliar with pattr, I can at least tell them to put synthesis parameters into one long message and send it to mubu.concat. I have trouble telling them to list segmentation parameters in a message like this, because there is no easy way to interface with the dynamically loaded patches from the top level patch

Make sense? I don't have an obvious solution in mind; looking for ideas... Thanks!

On Mon, Apr 29, 2024 at 8:29 AM einbond @.***> wrote:

Hello Chris, this is supposed to be built into each analysis module (camu.process.* — see screenshot). Each relevant attribute of mubu.process or pipo is listed in the pattr objects on the right. Of course if the segmentation module changes, then the attributes may change, but if the attributes are available they will be recalled. Do you think there needs to be something more or different? 

Screenshot.2024-04-29.at.15.23.40.png (view on web) https://github.com/ircam-ismm/catart-mubu/assets/14821637/b81ba55a-1bc8-4fa3-96f5-d32efa6349e9

— Reply to this email directly, view it on GitHub https://github.com/ircam-ismm/catart-mubu/issues/116#issuecomment-2082757112, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIRYDCYMYHVRQRMOQZFGLGDY7ZDLZAVCNFSM6AAAAABGJMRSC6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBSG42TOMJRGI . You are receiving this because you were mentioned.Message ID: @.***>

einbond commented 4 months ago

Some things to consider: - if I put in onseg settings then switch to chop, then back to onseg, those settings are lost

But if you save the onseg setting with pattr, then when you return to onseg, you can recall the pattr preset

  • there doesn't seem to be an intuitive way to send values to the analysis module from outside the patcher

In catoracle, I have a receive at the inlet to the bpatcher containing the camu.process.* modules, so you can send any values there, they are passed through to the first inlet of the module, and it always has the same address whatever module the bpatcher loads. This would be easy to add to camu.analysis. And/or we could just connect the right outlet of the route object so that unmatched messages go through to the bpatcher

  • could there be some pattr / saving mechanism one level above the patches, directly in the corpus.analysis (or camu.analysis) patch? Just to give you an example from teaching: With students who are unfamiliar with pattr, I can at least tell them to put synthesis parameters into one long message and send it to mubu.concat. I have trouble telling them to list segmentation parameters in a message like this, because there is no easy way to interface with the dynamically loaded patches from the top level patch Make sense? I don't have an obvious solution in mind; looking for ideas... Thanks!

I think the combination of the two suggestions above would give you what you need

einbond commented 4 months ago
Screenshot 2024-04-29 at 18 17 24

I would make the commit myself, but somehow my branches and local versions have gotten all tangled!

einbond commented 4 months ago

Oh wait, I think I was looking at the wrong branch, those features are already there. Thanks @diemoschwarz !

Screenshot 2024-04-29 at 18 22 21
diemoschwarz commented 4 months ago

Right on! This should go into camu.analysis in branch wip-analysis. Great use case, @christophertrapani , we should make an example out of this.

diemoschwarz commented 4 months ago

Before we merge this into master, we need to find a solution to the menu sync problem.

I agree that the internal menu is useful. Here is how it could be sync'ed to the external one, let's see which one is the least hassle (e.g. requiring specific connections b/w umenu and camu.analysis):

  • set the internal menu by argument/message (by default everything is available, or nothing?)
  • query the external menu by cycling through items (because we don't want the dump output to be connected mandatorily)
  • some nifty pattr/attr querying of the external menu
  • use camu.analysis in a bpatcher just showing the internal menu, add an "open" button (this would get rid of the external menu, but requires giving the allowed processes as argument)
  • anything else?

How about this: