Notifications
Clear all

Macro knob CC assignment question involving embedded layers

10 Posts
2 Users
0 Likes
374 Views
(@craigr68)
Member
Joined: 3 years ago
Posts: 210
Topic starter  

@getdunne

Is this supposed to happen with macro knobs of embedded layers?  (Screenshots zip attached)

1.jpg - shows the embedded patch in front, with the top level patch behind it - it just contains an initialized patch.  Notice Macro1 has no CC assigned

2.jpg - Then I choose 02 Synths patch and again no CC assigned.  That's how I want it and that's how I saved it prior.

3.jpg - Then I choose Syntronik patch where CC1 is now assigned to macro.  Again, this was how I had saved it prior.

4.jpg - Then I go back to the 02 Synths patch but now CC1 has carried forward to this patch for some reason.  I would think it would go back to no CC assigned.  And any other patch I open after that has CC1 assigned.

 

This topic was modified 2 years ago by craigr68

   
Quote
(@getdunne)
Illustrious Member Admin
Joined: 5 years ago
Posts: 4410
 
Posted by: @craigr68

Is this supposed to happen with macro knobs of embedded layers?

No, this is not happening by design. You've basically discovered a circumstance which I hadn't planned for, namely switching patches in an embedded Unify instance.

I agree that since CC/knob assignments are preserved for embedded Unify instances in other circumstances (specifically, when the outer-layer patch is saved and subsequently re-loaded), it's reasonable to expect it to happen here as well.

Thanks for bringing this to my attention. I'll look into it, and see if I can address it in code.


   
ReplyQuote
(@craigr68)
Member
Joined: 3 years ago
Posts: 210
Topic starter  

After thinking about this more, I realized I don't really understand where embedded patch macro cc assignments come from.  I would have thought they come from however I save the patch, whether I saved it in a non-embedded patch or in an embedded patch.  "Non-Embedded.png" shows what the patch looks like not embedded.  It shows my CC assignments are nothing like the embedded ones which are shown in "Embedded.png".  For my purposes, I would like to see the two be the same. 

Although another thing I'm running into in an embedded patch is, if you have a link in the top layer such as "inst/1/plugin/Layer1 Vol", and you load a new embedded patch, the names have to match or the link turns red.  I don't know what to do about that either.  What I'm trying to do is set a standard macro naming pattern.  With ability to create 8 macro banks, that might work out ok.

This post was modified 2 years ago 3 times by craigr68

   
ReplyQuote
(@getdunne)
Illustrious Member Admin
Joined: 5 years ago
Posts: 4410
 
Posted by: @craigr68

I don't really understand where embedded patch macro cc assignments come from.

Every patch includes a saved CC number for each macro knob, but Unify presently only pays attention to these when loading a patch which includes embedded Unify instances. At the top level, these CC numbers are overridden by the current assignments, saved in the Unify.settings file, which are intended to reflect whatever hardware MIDI controller(s) you have. These assignments can also be swapped out as a group by loading a CC Assignment preset; this was intended for cases where you switch from one combination of hardware MIDI controllers to another.

As I said before, all of this was defined before Unify had support for embedded Unify instances. Your experience has shown that this not only requires that Unify remember CC assignments for embedded instances, but that you should also be able to load presets inside embedded instances, complete with their CC assignments. As I said, I'll be looking into this for the next update. Unify has been out for nearly three years, and you're the first person to point this out.

UPDATE: I think I have this working as expected now.


   
ReplyQuote
(@craigr68)
Member
Joined: 3 years ago
Posts: 210
Topic starter  
Posted by: @getdunne

load presets inside embedded instances, complete with their CC assignments

Yes, that's what I was thinking.  In coding, I know too well how unexpected things like this occur.  Thanks so much for explaining and looking into this.


   
ReplyQuote
(@craigr68)
Member
Joined: 3 years ago
Posts: 210
Topic starter  

I hope I'm not being a pest.  But I think there's a second problem with changing embedded patches on the fly that I eluded to above.  I thought about it a little more.  It has to do with the macro links in the top level patch.  Take for instance one of John's Megamagic Pads loaded as an embedded layer.  He has macro1 assigned to "Filter Cutoff -".  So, in the top level macro1 you need to have the link be "inst/1/plugin/Filter Cutoff -".  If I change the embedded patch to some other patch where the name of macro1 will be something else - now the link will show in red and will be invalid.  Is there a way that the top level macro1 link could be generic - like "inst/1/plugin/macro1" so that it doesn't have to match the name?  Maybe you could have both ways of linking - generic and by name.  I'm running into this problem when I'm sending Osc commands to change the embedded patch and it diminishes much of the Osc feature.

This post was modified 2 years ago by craigr68

   
ReplyQuote
(@getdunne)
Illustrious Member Admin
Joined: 5 years ago
Posts: 4410
 
Posted by: @craigr68

I hope I'm not being a pest.

Not at all.

Is there a way that the top level macro1 link could be generic... ?

Yes. Use e.g. /inst/1/plugin/#0 for Macro 1, /inst/1/plugin/#1 for Macro 2, etc. This works for any plug-in, to reference the parameters by numeric index. Note the index sequence starts at 0, not 1.

This isn't in the online manual yet, because it's still officially experimental, but I'm pretty sure John has shown it in at least one video.


   
ReplyQuote
(@craigr68)
Member
Joined: 3 years ago
Posts: 210
Topic starter  

I tried assigning that to Macro1 in the top level and it comes up red.  (Screenshot) -

Update: NEVERMIND - IT DOES WORK - it must have been how I copied and pasted it.

This post was modified 2 years ago by craigr68

   
ReplyQuote
(@getdunne)
Illustrious Member Admin
Joined: 5 years ago
Posts: 4410
 
Posted by: @craigr68

I tried assigning that to Macro1 in the top level and it comes up red.

Sorry, I gave you the OSC version. Remove the leading "/" for use in parameter links.


   
ReplyQuote
(@craigr68)
Member
Joined: 3 years ago
Posts: 210
Topic starter  

@getdunne 

Ok, that's what happened.  I pasted it in with the slash.  Then somehow I removed the slash and it worked.  Cool.


   
ReplyQuote
Share: