Flow Chart Instrument

[Ugur Guney]

# Hi All,
# I'm Ugur from Turkey. I took a Java course at University and for
term project I chose to write a GUI for building Csound instruments in
a flow chart manner. (I attached the standalone FrontEnd.jar file) I
talked with Steven Yi about to integrating this project into Blue.
# The idea is as follows:
# The UI will look like a PD or Reaktor interface, in which there are
unit's of which input/outputs are connected with cables. The units are
small codes pieces (includes one or more opcodes typed with arguments
as in manual) The interface analyzes that code, and prepares the
graphical input and outputs acording that code. (and it controls the
code whether it match the correct Csound synthax) There should be a
unit library which includes all opcodes, and a library for user typed
code pieces.
# Then user connects the units together. (the correctness of this
connection have to be controlled by the program. An output cannot
plugged to another output or a k-rate variable cannot plugged to
a-rate variable)
# If all input variables are plugged or set to a constant value (or a
p-field) in the text editor user can print the corresponding Csound
instrument code. The interface gives different variable names to
different cables, and construct the code by combining the code pieces.

# What do you think about this?
# And sorry for my bad coding :-) This was my first project in Java.
And I even didn't know the existence of array lists etc. It includes
many bugs and can't do everything I wrote. The Code have to written
from scratch. I attached it to give you some idea. Gooddays!

-ugur guney-

[Steven Yi]

Hi All,

Ugur had contacted about integrating his instrument building frontend
about two weeks ago now and we were waiting until he was finished with
the project for his class before discussing (so as not to affect his
grade in any way).  Since he is now finished and has sent the code
along to me, I've pushed it into blue's CVS as a new
FlowGraphInstrument class.  The parts which are mostly Ugur's will be
in sub-parts and currently am planning to make that more of a reusable
component, with the end goal of reusing it for other instruments,
particularly BlueSynthBuilder.  If we can get that together, then we
would have a very Reaktor-esque instrument building possibility.

Already there's a good bit of things I'd like to modify to get the
code to be more inline with the blue coding conventions and
architecture.  And while the frontend is functional for its original
purpose, I think we'll need to expand on the original ideas from Ugur
to allow for some more flexibility.

I've also taken a look at how Cabel is implemented to get some ideas
on how to go about implementing the compilation from the graph model
to csound instrument code.  Cabel makes every module (box) into a
user-defined opcode, and the instrument then is hooking up the
generated UDO's.  This has some good features and allows for creating
modules with "setksmps 1", which can be very useful.

In terms of the UI, I think we can make it a bit simpler by removing
the left pane with the code tree and making the main edit pane be one
where you right-click and add a module from a popup menu.  It'd open
up some screen real-estate which might be necessary.

I think too we need to make the modules not have its contents be
editable.  I am thinking it would be best to have a program-wide
library of modules which you can manage in a separate dialog.  If you
need a new module you would first add it in the libary, then go and
add it your patch from the popup menu.

Modules could work by having all ports which are inputs not only be
able to be hooked into, but also have default values so that if a port
isn't connected to from an output from another module, then it can
still generate with the default instead.

Very tired now so will be retiring for the night; looking forward to
working on this with everyone!

steven


On 1/31/06, sokratesla <ugurguney@...> wrote:

> # Hi All,
> # I'm Ugur from Turkey. I took a Java course at University and for
> term project I chose to write a GUI for building Csound instruments in
> a flow chart manner. (I attached the standalone FrontEnd.jar file) I
> talked with Steven Yi about to integrating this project into Blue.
> # The idea is as follows:
> # The UI will look like a PD or Reaktor interface, in which there are
> unit's of which input/outputs are connected with cables. The units are
> small codes pieces (includes one or more opcodes typed with arguments
> as in manual) The interface analyzes that code, and prepares the
> graphical input and outputs acording that code. (and it controls the
> code whether it match the correct Csound synthax) There should be a
> unit library which includes all opcodes, and a library for user typed
> code pieces.
> # Then user connects the units together. (the correctness of this
> connection have to be controlled by the program. An output cannot
> plugged to another output or a k-rate variable cannot plugged to
> a-rate variable)
> # If all input variables are plugged or set to a constant value (or a
> p-field) in the text editor user can print the corresponding Csound
> instrument code. The interface gives different variable names to
> different cables, and construct the code by combining the code pieces.
>
> # What do you think about this?
> # And sorry for my bad coding :-) This was my first project in Java.
> And I even didn't know the existence of array lists etc. It includes
> many bugs and can't do everything I wrote. The Code have to written
> from scratch. I attached it to give you some idea. Gooddays!
>
> -ugur guney-
>
>
>

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Bluemusic-devel mailing list
Bluemusic-devel@...
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel

[Ugur Guney]

On 2/1/06, Steven Yi <stevenyi@...> wrote:
> Cabel makes every module (box) into a
> user-defined opcode, and the instrument then is hooking up the
> generated UDO's.  This has some good features and allows for creating
> modules with "setksmps 1", which can be very useful.

# Does making an UDO for every unit effect the performance? If yes, we
should prepare an option to select either to create an UDO (if
necessary, eg. to set setksmps 1) or create embedded code.

> In terms of the UI, I think we can make it a bit simpler by removing
> the left pane with the code tree and making the main edit pane be one
> where you right-click and add a module from a popup menu.  It'd open
> up some screen real-estate which might be necessary.

# I used a left pane there in order to learn about how to use JTree's.
After implementation of the pop-up menu the tree will get unnecessary.

> I think too we need to make the modules not have its contents be
> editable.  I am thinking it would be best to have a program-wide
> library of modules which you can manage in a separate dialog.  If you
> need a new module you would first add it in the libary, then go and
> add it your patch from the popup menu.

# OK. Then the responsibility of creating a Unit from existing code
pieces belongs to that interface which adds new Units to the library
(call it "UnitLibraryEditor")
# But, I think, the name of a Unit should be editable. One can use
oscil opcode for different purposes like as an sound generator or as
an envelope etc. The usage depends to its context and can be revealed
by its title.
# And, what about different shapes or icons for units of different
purposes? (an ADSR shape for envelopes etc.) (may be in next versions)

> Modules could work by having all ports which are inputs not only be
> able to be hooked into, but also have default values so that if a port
> isn't connected to from an output from another module, then it can
> still generate with the default instead.

# Can we make something like this: The Units come with default values
assigned to their input ports. Then, by right-clicking on a port, user
can choose 1) to assign another constant value to that variable, 2) to
set a p-field 3) to connect a blue object (like LineObject) 4) to
connect another avaible port (pop-up menu should list all possible
ports with same rate)


# Another matter: The variables can be added, multiplied etc. in Csound.
aout oscil 10000, klfo+kfreq, 1
Because the Unit code cannot be edited, this type of operations can't
be done easily as writing code. We have to make special Unit's for
arithmetic (or orther kind of) operations. (perhaps these may placed
in "Math" sub-menu)

-ugur-


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Bluemusic-devel mailing list
Bluemusic-devel@...
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel

[Michael Bechard]

Sounds pretty cool, guys.  I'd love to help, but I'm
caught up in too many other projects now.  I can't
wait to see what comes of this though.

Michael Bechard

--- Steven Yi <stevenyi@...> wrote:

> Hi All,
>
> Ugur had contacted about integrating his instrument
> building frontend
> about two weeks ago now and we were waiting until he
> was finished with
> the project for his class before discussing (so as
> not to affect his
> grade in any way).  Since he is now finished and has
> sent the code
> along to me, I've pushed it into blue's CVS as a new
> FlowGraphInstrument class.  The parts which are
> mostly Ugur's will be
> in sub-parts and currently am planning to make that
> more of a reusable
> component, with the end goal of reusing it for other
> instruments,
> particularly BlueSynthBuilder.  If we can get that
> together, then we
> would have a very Reaktor-esque instrument building
> possibility.
>
> Already there's a good bit of things I'd like to
> modify to get the
> code to be more inline with the blue coding
> conventions and
> architecture.  And while the frontend is functional
> for its original
> purpose, I think we'll need to expand on the
> original ideas from Ugur
> to allow for some more flexibility.
>
> I've also taken a look at how Cabel is implemented
> to get some ideas
> on how to go about implementing the compilation from
> the graph model
> to csound instrument code.  Cabel makes every module
> (box) into a
> user-defined opcode, and the instrument then is
> hooking up the
> generated UDO's.  This has some good features and
> allows for creating
> modules with "setksmps 1", which can be very useful.
>
> In terms of the UI, I think we can make it a bit
> simpler by removing
> the left pane with the code tree and making the main
> edit pane be one
> where you right-click and add a module from a popup
> menu.  It'd open
> up some screen real-estate which might be necessary.
>
> I think too we need to make the modules not have its
> contents be
> editable.  I am thinking it would be best to have a
> program-wide
> library of modules which you can manage in a
> separate dialog.  If you
> need a new module you would first add it in the
> libary, then go and
> add it your patch from the popup menu.
>
> Modules could work by having all ports which are
> inputs not only be
> able to be hooked into, but also have default values
> so that if a port
> isn't connected to from an output from another
> module, then it can
> still generate with the default instead.
>
> Very tired now so will be retiring for the night;
> looking forward to
> working on this with everyone!
>
> steven
>
>
> On 1/31/06, sokratesla <ugurguney@...> wrote:
> > # Hi All,
> > # I'm Ugur from Turkey. I took a Java course at
> University and for
> > term project I chose to write a GUI for building
> Csound instruments in
> > a flow chart manner. (I attached the standalone
> FrontEnd.jar file) I
> > talked with Steven Yi about to integrating this
> project into Blue.
> > # The idea is as follows:
> > # The UI will look like a PD or Reaktor interface,
> in which there are
> > unit's of which input/outputs are connected with
> cables. The units are
> > small codes pieces (includes one or more opcodes
> typed with arguments
> > as in manual) The interface analyzes that code,
> and prepares the
> > graphical input and outputs acording that code.
> (and it controls the
> > code whether it match the correct Csound synthax)
> There should be a
> > unit library which includes all opcodes, and a
> library for user typed
> > code pieces.
> > # Then user connects the units together. (the
> correctness of this
> > connection have to be controlled by the program.
> An output cannot
> > plugged to another output or a k-rate variable
> cannot plugged to
> > a-rate variable)
> > # If all input variables are plugged or set to a
> constant value (or a
> > p-field) in the text editor user can print the
> corresponding Csound
> > instrument code. The interface gives different
> variable names to
> > different cables, and construct the code by
> combining the code pieces.
> >
> > # What do you think about this?
> > # And sorry for my bad coding :-) This was my
> first project in Java.
> > And I even didn't know the existence of array
> lists etc. It includes
> > many bugs and can't do everything I wrote. The
> Code have to written
> > from scratch. I attached it to give you some idea.
> Gooddays!
> >
> > -ugur guney-
> >
> >
> >
>
>
>

-------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do
> you grep through log files
> for problems?  Stop!  Download the new AJAX search
> engine that makes
> searching your log files as easy as surfing the
> web.  DOWNLOAD SPLUNK!
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
> _______________________________________________
> Bluemusic-devel mailing list
> Bluemusic-devel@...
>
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluemusic-devel mailing list
Bluemusic-devel@...
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel

[Steven Yi]

Hi Ugur,

> # Does making an UDO for every unit effect the performance? If yes, we
> should prepare an option to select either to create an UDO (if
> necessary, eg. to set setksmps 1) or create embedded code.

It does affect performance but may be necessary in some cases for
feedback and filters.  I think having an option to generate as a UDO
or to inline the code would be good, but that will mean we will have
to do a little more code work to determine the inputs and outputs from
the UDO if that gets generated.  But I definitely think it should be
an options.


> > I think too we need to make the modules not have its contents be
> > editable.  I am thinking it would be best to have a program-wide
> > library of modules which you can manage in a separate dialog.  If you
> > need a new module you would first add it in the libary, then go and
> > add it your patch from the popup menu.
>
> # OK. Then the responsibility of creating a Unit from existing code
> pieces belongs to that interface which adds new Units to the library
> (call it "UnitLibraryEditor")

Sounds good to call it that.  We can reuse code from the
CodeLibraryDialog editor for this purpose I think.

> # But, I think, the name of a Unit should be editable. One can use
> oscil opcode for different purposes like as an sound generator or as
> an envelope etc. The usage depends to its context and can be revealed
> by its title.

I don't think this is a good idea to make the unit name editable, as
then it will make it difficult to understand what things are if they
are not always meaning what they say.  I would prefer to either add
the ability to add comment text to the patches or to add comments as a
field in the unit which can show as a tooltip on rollover.

> # And, what about different shapes or icons for units of different
> purposes? (an ADSR shape for envelopes etc.) (may be in next versions)

I like the idea of icons but we'd have to manage to find a good way to
do that and still maintain a small filesize.  We can wait until the
next version. ^_^

> > Modules could work by having all ports which are inputs not only be
> > able to be hooked into, but also have default values so that if a port
> > isn't connected to from an output from another module, then it can
> > still generate with the default instead.
>
> # Can we make something like this: The Units come with default values
> assigned to their input ports. Then, by right-clicking on a port, user
> can choose 1) to assign another constant value to that variable, 2) to
> set a p-field 3) to connect a blue object (like LineObject) 4) to
> connect another avaible port (pop-up menu should list all possible
> ports with same rate)

I was thinking we may need to separate into having different type
objects, some which are units, some which can be constants.  For
Pfields, I think we should create a pfield object which can be set to
have both number of ports and labels for those ports, with only one
pfield object per instrument.  It can be a fixed object at the top of
the canvas that will always be there and have at least p1, p2, and p3
to start.


> # Another matter: The variables can be added, multiplied etc. in Csound.
> aout oscil 10000, klfo+kfreq, 1
> Because the Unit code cannot be edited, this type of operations can't
> be done easily as writing code. We have to make special Unit's for
> arithmetic (or orther kind of) operations. (perhaps these may placed
> in "Math" sub-menu)

Maybe we should make an expression object that will text replace the
inputs with what comes in and output the whole text-replaced text to
the output, rather than to create a Math submenu and having to create
a new object for every math operation.  It'll be a bit more generic
and flexible as it becomes something like a macro.

steven


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Bluemusic-devel mailing list
Bluemusic-devel@...
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel

[Steven Yi]

Thanks for the well wishes!  I was very excited when Ugur contacted me
about this initially as the code is fairly minimal and easy for me to
work with and I think it'll work out well within blue.  Best of luck
with your many projects and hopefully when we can get this up and
running, any feedback and advice you'll have time to give then would
be very much appreciated!

steven

On 2/1/06, Michael Bechard <gothmagog@...> wrote:

> Sounds pretty cool, guys.  I'd love to help, but I'm
> caught up in too many other projects now.  I can't
> wait to see what comes of this though.
>
> Michael Bechard
>
> --- Steven Yi <stevenyi@...> wrote:
>
> > Hi All,
> >
> > Ugur had contacted about integrating his instrument
> > building frontend
> > about two weeks ago now and we were waiting until he
> > was finished with
> > the project for his class before discussing (so as
> > not to affect his
> > grade in any way).  Since he is now finished and has
> > sent the code
> > along to me, I've pushed it into blue's CVS as a new
> > FlowGraphInstrument class.  The parts which are
> > mostly Ugur's will be
> > in sub-parts and currently am planning to make that
> > more of a reusable
> > component, with the end goal of reusing it for other
> > instruments,
> > particularly BlueSynthBuilder.  If we can get that
> > together, then we
> > would have a very Reaktor-esque instrument building
> > possibility.
> >
> > Already there's a good bit of things I'd like to
> > modify to get the
> > code to be more inline with the blue coding
> > conventions and
> > architecture.  And while the frontend is functional
> > for its original
> > purpose, I think we'll need to expand on the
> > original ideas from Ugur
> > to allow for some more flexibility.
> >
> > I've also taken a look at how Cabel is implemented
> > to get some ideas
> > on how to go about implementing the compilation from
> > the graph model
> > to csound instrument code.  Cabel makes every module
> > (box) into a
> > user-defined opcode, and the instrument then is
> > hooking up the
> > generated UDO's.  This has some good features and
> > allows for creating
> > modules with "setksmps 1", which can be very useful.
> >
> > In terms of the UI, I think we can make it a bit
> > simpler by removing
> > the left pane with the code tree and making the main
> > edit pane be one
> > where you right-click and add a module from a popup
> > menu.  It'd open
> > up some screen real-estate which might be necessary.
> >
> > I think too we need to make the modules not have its
> > contents be
> > editable.  I am thinking it would be best to have a
> > program-wide
> > library of modules which you can manage in a
> > separate dialog.  If you
> > need a new module you would first add it in the
> > libary, then go and
> > add it your patch from the popup menu.
> >
> > Modules could work by having all ports which are
> > inputs not only be
> > able to be hooked into, but also have default values
> > so that if a port
> > isn't connected to from an output from another
> > module, then it can
> > still generate with the default instead.
> >
> > Very tired now so will be retiring for the night;
> > looking forward to
> > working on this with everyone!
> >
> > steven
> >
> >
> > On 1/31/06, sokratesla <ugurguney@...> wrote:
> > > # Hi All,
> > > # I'm Ugur from Turkey. I took a Java course at
> > University and for
> > > term project I chose to write a GUI for building
> > Csound instruments in
> > > a flow chart manner. (I attached the standalone
> > FrontEnd.jar file) I
> > > talked with Steven Yi about to integrating this
> > project into Blue.
> > > # The idea is as follows:
> > > # The UI will look like a PD or Reaktor interface,
> > in which there are
> > > unit's of which input/outputs are connected with
> > cables. The units are
> > > small codes pieces (includes one or more opcodes
> > typed with arguments
> > > as in manual) The interface analyzes that code,
> > and prepares the
> > > graphical input and outputs acording that code.
> > (and it controls the
> > > code whether it match the correct Csound synthax)
> > There should be a
> > > unit library which includes all opcodes, and a
> > library for user typed
> > > code pieces.
> > > # Then user connects the units together. (the
> > correctness of this
> > > connection have to be controlled by the program.
> > An output cannot
> > > plugged to another output or a k-rate variable
> > cannot plugged to
> > > a-rate variable)
> > > # If all input variables are plugged or set to a
> > constant value (or a
> > > p-field) in the text editor user can print the
> > corresponding Csound
> > > instrument code. The interface gives different
> > variable names to
> > > different cables, and construct the code by
> > combining the code pieces.
> > >
> > > # What do you think about this?
> > > # And sorry for my bad coding :-) This was my
> > first project in Java.
> > > And I even didn't know the existence of array
> > lists etc. It includes
> > > many bugs and can't do everything I wrote. The
> > Code have to written
> > > from scratch. I attached it to give you some idea.
> > Gooddays!
> > >
> > > -ugur guney-
> > >
> > >
> > >
> >
> >
> >
> -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do
> > you grep through log files
> > for problems?  Stop!  Download the new AJAX search
> > engine that makes
> > searching your log files as easy as surfing the
> > web.  DOWNLOAD SPLUNK!
> >
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
> > _______________________________________________
> > Bluemusic-devel mailing list
> > Bluemusic-devel@...
> >
> https://lists.sourceforge.net/lists/listinfo/bluemusic-devel
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Bluemusic-devel mailing list
> Bluemusic-devel@...
> https://lists.sourceforge.net/lists/listinfo/bluemusic-devel
>

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Bluemusic-devel mailing list
Bluemusic-devel@...
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel

[Ugur Guney]

> > # But, I think, the name of a Unit should be editable. One can use
> > oscil opcode for different purposes like as an sound generator or as
> > an envelope etc. The usage depends to its context and can be revealed
> > by its title.
>
> I don't think this is a good idea to make the unit name editable, as
> then it will make it difficult to understand what things are if they
> are not always meaning what they say.  I would prefer to either add
> the ability to add comment text to the patches or to add comments as a
> field in the unit which can show as a tooltip on rollover.

# There can be two main branch of units in the UnitLibrary. First one
is the units generated for all opcodes. They comes with Blue, and are
unchangeable. Their name is the name of of the opcode used in it.
Second is UserDefinedUnits. User should write the code and give it a
name using UnitLibraryEditor.
# The interface shows the name of the Unit, on its box.
# All Units have comments, which can be edited by right-clicking on a
unit. When the cursor is on a unit, status bar displays the name and
comment.

> > > Modules could work by having all ports which are inputs not only be
> > > able to be hooked into, but also have default values so that if a port
> > > isn't connected to from an output from another module, then it can
> > > still generate with the default instead.
> >
> > # Can we make something like this: The Units come with default values
> > assigned to their input ports. Then, by right-clicking on a port, user
> > can choose 1) to assign another constant value to that variable, 2) to
> > set a p-field 3) to connect a blue object (like LineObject) 4) to
> > connect another avaible port (pop-up menu should list all possible
> > ports with same rate)
>
> I was thinking we may need to separate into having different type
> objects, some which are units, some which can be constants.  For
> Pfields, I think we should create a pfield object which can be set to
> have both number of ports and labels for those ports, with only one
> pfield object per instrument.  It can be a fixed object at the top of
> the canvas that will always be there and have at least p1, p2, and p3
> to start.

# I have an idea for preventing the cable chaos (not a genuine idea,
of course) We have to implement something like "remote connection".
This time the data does not goes through wires, but with, err...,
electromagnetic waves :-). Right-clicking on a port should list all
avaible ports to connect, and selecting makes a mark on the ports, and
when mouse comes over a port, statusbar shows where it is connected.
# (And we must think about how cables should look like. Or are
straight, black lines suitable?)
# There will be a stationary Unit placed at the top, with only
outputs, named pN.

# May be the interface should give a warning when a port uses its default value.

> > # Another matter: The variables can be added, multiplied etc. in Csound.
> > aout oscil 10000, klfo+kfreq, 1
> > Because the Unit code cannot be edited, this type of operations can't
> > be done easily as writing code. We have to make special Unit's for
> > arithmetic (or orther kind of) operations. (perhaps these may placed
> > in "Math" sub-menu)
>
> Maybe we should make an expression object that will text replace the
> inputs with what comes in and output the whole text-replaced text to
> the output, rather than to create a Math submenu and having to create
> a new object for every math operation.  It'll be a bit more generic
> and flexible as it becomes something like a macro.

# Oh, I understand what you mean. There have to be three type of
units, "Expression"s, "Normal :-) Unit"s, fixed "P-Field Unit".
Expression is a blank unit which can be edited by a JDialog. It
evaluates the expression in it and creates necessary input ports and
one output port. its output type is same as its highest-rate operand.
or should all operand have same rate.
# When an Expression is connected to a input port, its content is copied.
# An Expression may be a constant number too.

# There can be an "Assignment Unit" with opcode "=". This can be used
for initializations of p-fields etc.?

-uguur


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Bluemusic-devel mailing list
Bluemusic-devel@...
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel