Comments (7)
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!_
from eigenharp.
any thoughts on this @carvingCode ?
from eigenharp.
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.
from eigenharp.
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 [email protected] 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
from eigenharp.
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 [email protected] 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 [email protected]:
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
from eigenharp.
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.
from eigenharp.
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 [email protected]:
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
from eigenharp.
Related Issues (20)
- creator - fingerer support
- creator - bow control
- creator - basic configs more like factory
- creator - move from scripts/module to top level
- createcello HOT 1
- more "basic" conf. ?? HOT 2
- Creator - Better EigenBrowser interaction HOT 3
- tau folder contains no createdevice.bc HOT 1
- Add column and row set to createkeygroupoutput.bc
- Add 'mode key row end relative' when creating outputs HOT 1
- Pico Manager not finding Pico HOT 2
- Create Light Scroller (illuminator agent) HOT 1
- Flash persistence and scheduler to metronome connect
- EigenBrowser : OSX El Capitan 10.11.3
- creator - drummer control
- creator - instrument control
- creator - mixer control
- creator - octave control
- creator - stringer support
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from eigenharp.