Belcanto to un create/erase/delete either an input or output inside a gateway or rig input /output

[keymanpal]

Hi All...

Still working on Controlling the NEURONVS...
I'm creating a link latch to a rig for this ... stuck on the above (title)

cheers

[TheTechnobear]

we need to think about this, this is similar in some respects to discussion ive been having with +carvingCode.

The question is how low level do we want the 'modules' to be, if we make them very low level
e.g. worst case is 1 module executes 1 belcanto command
then we will end up with very large (and complex) config files.

Now Im not saying this is 'wrong', its not... but is it desirable?

Lets take your example, would it be better to create a module that had a bit more in it?
e.g.
(ok, I dont know what your doing exactly, so this is very rough)
addLatchedInputToAURig... which added latch to keygroup output, created a input on an EXISTING AU rig, and connected up that input in the rig, to the relevant parts in the rig)

This is basically what I did with recorder.
( you will note though, that im not totally consistent, as createkeygroupoutput is low-level!)

I repeat, im not saying, this is the best way forward... as to be honest im not sure, but I think its worth thinking.

(my only issue with adding lots of low-level modules, is once you've added them, removing is difficult as you will break peoples configs!_

[TheTechnobear]

any thoughts on this @carvingCode ?

[keymanpal]

addLatchedInputToAURig... YES that is my intention in the end!
This one in particular is deceiving (Eigenkey as a Knob) so lots of connections.

For what I can grasp i agree with you Mark, not fragmenting everything to much.

[carvingCode]

Something like 'createkeygroup' makes sense as low level, although it could
be argued that creating true 'modules' with everything necessary to create
a particular functionality or behavior may be more useful. The latter
would probably require more passed variables for module settings.

Calling 'createkeygroup' then turning around and calling
'createkeygroupoutput' un-associates something that most always needs to be
essentially one procedure. I actually prefer, creating keygroup, output
and then linking all in one place - it makes it easier to debug.

While we're on this, I was thinking that its may be time to create a
director structure or naming structure. There's a growing number of
'createX' files. It may make it easier to find what is needed if they are
grouped, either by name or by folder.

On Fri, Jun 21, 2013 at 7:44 AM, keymanpal notifications@github.com wrote:

addLatchedInputToAURig... YES that is my intention in the end!
This one in particular is deceiving (Eigenkey as a Knob) so lots of
connections.

For what I can grasp i agree with you Mark, not fragmenting everything to
much.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-19811301
.

https://soundcloud.com/carvingcode > My compositions
http://randybrown.us > My blog

[carvingCode]

Another example would be the metronome. How often are you going to add a
metronome and not want to wire it to a Talker to toggle it on and off? Not
often. So why not create the metronome and metronome talker in one
procedure?

On Fri, Jun 21, 2013 at 7:59 AM, carvingcode carvingcode@gmail.com wrote:

Something like 'createkeygroup' makes sense as low level, although it
could be argued that creating true 'modules' with everything necessary to
create a particular functionality or behavior may be more useful. The
latter would probably require more passed variables for module settings.

Calling 'createkeygroup' then turning around and calling
'createkeygroupoutput' un-associates something that most always needs to be
essentially one procedure. I actually prefer, creating keygroup, output
and then linking all in one place - it makes it easier to debug.

While we're on this, I was thinking that its may be time to create a
director structure or naming structure. There's a growing number of
'createX' files. It may make it easier to find what is needed if they are
grouped, either by name or by folder.

On Fri, Jun 21, 2013 at 7:44 AM, keymanpal notifications@github.comwrote:

addLatchedInputToAURig... YES that is my intention in the end!
This one in particular is deceiving (Eigenkey as a Knob) so lots of
connections.

For what I can grasp i agree with you Mark, not fragmenting everything to
much.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-19811301
.

https://soundcloud.com/carvingcode > My compositions
http://randybrown.us > My blog

https://soundcloud.com/carvingcode > My compositions
http://randybrown.us > My blog

[TheTechnobear]

Yup, these are kinda my thoughts too ...

e.g. you will see that linkrigs creates a key group output, probably to be consistent createkeygroup and createtalker should also do the same.

Also, The addrecordertorigs was an experiment in adjusting rigs, and whilst it works its not very pretty as it has to know how to disconnect the rig. whilst this works here, its not really a scaleable approach.

Similarly, you will see with the rigs, they have the clock inputs and scheduler inputs in the base, theoretically this could be added by appropriate modules (e.g. add metronome, add recorder), but this complicates things a bit.

Finally, you could argue (rightly) that adding a recorder requires a metronome/clock, but then again, is it clock, or midi clock!

The fundamental problem is not having support for conditional code in the template, but this is in itself tricky...
its difficult (and slow, e.g. via bls/bcat) to inspect the eigenD model, so would have to probably be done in code.
Also, I think if we were able to have modules called within modules, this would also help, as we could then have some lower level 'functions' used by higher level modules.
For both these things, I think I will need to rewrite createsetup.sh in either python or java. Java I know very well, python I dont .. but has the advantage it integrates easily with eigend.
Will have to think about this and perhaps experiment with eigenD xrpc interface from java.

anyway, i think we are all thinking along similar lines... i.e trying to have 'higher level' modules, but without them being so high level, that we duplicate belcanto everywhere.

[carvingCode]

Yes, I've tried several times to get started with python for the sole
purpose of grokking EigenD. I know C. I think my main problem is with the
EigenD code itself. Not friendly at all, IMO.

On Fri, Jun 21, 2013 at 9:37 AM, Mark Harris notifications@github.comwrote:

Yup, these are kinda my thoughts too ...

e.g. you will see that linkrigs creates a key group output, probably to be
consistent createkeygroup and createtalker should also do the same.

Also, The addrecordertorigs was an experiment in adjusting rigs, and
whilst it works its not very pretty as it has to know how to disconnect the
rig. whilst this works here, its not really a scaleable approach.

Similarly, you will see with the rigs, they have the clock inputs and
scheduler inputs in the base, theoretically this could be added by
appropriate modules (e.g. add metronome, add recorder), but this
complicates things a bit.

Finally, you could argue (rightly) that adding a recorder requires a
metronome/clock, but then again, is it clock, or midi clock!

The fundamental problem is not having support for conditional code in the
template, but this is in itself tricky...
its difficult (and slow, e.g. via bls/bcat) to inspect the eigenD model,
so would have to probably be done in code.
Also, I think if we were able to have modules called within modules, this
would also help, as we could then have some lower level 'functions' used by
higher level modules.
For both these things, I think I will need to rewrite createsetup.sh in
either python or java. Java I know very well, python I dont .. but has the
advantage it integrates easily with eigend.
Will have to think about this and perhaps experiment with eigenD xrpc
interface from java.

anyway, i think we are all thinking along similar lines... i.e trying to
have 'higher level' modules, but without them being so high level, that we
duplicate belcanto everywhere.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-19816153
.

https://soundcloud.com/carvingcode > My compositions
http://randybrown.us > My blog