classes of FlowGraphInstrument

[Ugur Guney]

# I want to make all classes and their resposibilities clear before
starting to code. I think this thinking process is more important than
writing the codes. After the specification, the implementations will
be easier than pondering before the screen. So, this is the
explanation why I am talking to much but doesn't write any code :-)

# I'm making a chart of classes and their responsibilities:

# Port:
# This class was not in my project, but after a while I strongly feel
its necessity.
# A Port should know wheter it is output or input, to which Opcode
(and Unit) it belongs, whether a Cable is plugged to it, if yes, to
which other ports it is connnected. (an output Port may be connected
to many input ports)
# This class will be very useful at the end, when it comes to create
the Csound code. (Furthermore when this ınput/outputs are defined as
explicit classes, it'll get easier to detect determine wheter mouse
clicked on it etc.)
# Every port is related with variable rate type, and a name. The name
will be the arguments for each opcode in the manual. Different types
cannot be connected.

# Opcode: (this comes to my mind now)
# Opcode has one output port (if necessary) and one or more input
ports (if necessary), has a name and knows to which Unit it belongs.

# Unit:
# There are two types of units: Expressions and Units.
# Unit's have an array of Opcodes, has a position, has a name and
commenti knows either it will get a inline code or a UDO.
# Expressions have a expressionEvaluator method. According the
mathematical expression gave to that method it sets proper ports.

# Cable:
# A Cable knows between which input and output ports it is connected.

# FlowGraphInstrument:
# It has Units and Cables. Its addCable method is responsible for
correct connections.
int addCable(Port input, Port output);
returns OUT_TO_OUT or similar static int values according to false
connections, CONNECTED for correct ones etc.
# and finally the hardest method: public String generateInstrument()
which, if I understood correctly, generates the Csound instrument code!

# This is the draft structure I think to build. Do you have any
objections, or properties want to add.
# next I'll send a mail about the classes of graphical interface.

-ugur-
N¬HY޵隊X¬²š'²ŠŞu¼’¦[§‰ÜŒ¨º
ަØk¢è!–ˆŠW¬~Šé®†åzk¶ŠC£ 塧m…éŞÀ@^ǚ­È^ž§zØZ¶f¤zËj·!Šx2¢êå¢â•ë±æ¬É«,º·âža{›å,àHòÔ4¨m¶Ÿÿ±éZ²ëjY‚w­şÇ¥rg–y$‰Ó~7Ù¸Û}8ó§Z´×®6[žšë"qׯzYšŠX§‚X¬´nzk¬‰Ç^½éeŠËl²‹«qç讧zØm¶›?şX¬¶Ë(º·~Šàzw­şX¬¶ÏåŠËbú?n[žšë"qׯz

[Steven Yi]

Hi Ugur,

I apologize in advance I'll probably be a little slow to reply to some
of these as it is a big issue to think about as like you I want to get
a good sense of the design before charging into coding, and also
because I think we should try to make it very robust so that the
infrastructure will last a long time.

I was thinking on the way to work today that perhaps expression
objects might not be the way to go.  It makes it complicated and also
adds room for error on the user's part, and I think we need to limit
the possibilities of errors.

I think we also need to make the abstractions very versatile such that
we can create all of the necessary parts from very few abstractions.
I have been thinking quite a bit about how PD and Reaktor work as well
as how Cabel is desgned. We should also look at CSBlocks as it is a
fairly well thought-out flow graph editing program for Csound. We also
need to take into account Csound inherent signal types and graph flow.

So, I am thinking that for Units, we need to be able to accept a-, k-,
i-, and S- type values (S- is a csound5-only string type).  We should
also probably support w- and f- signal types too, but t- rate signals
from CsoundAV I think we should ignore as it is not available in any
other csound.

I think we should have a base Unit type.  Instead of Expression
objects we should have Constant objects, similar to PD's number boxes.
 The constant can output a-, k-, i-, or S- values.  For expressions, I
think you were right in the beginning and it'll be better to do that
as a Unit so that the code is within the Unit and not accessible by
the user, so less chance of error.

I do not quite understand your Opcode class you mention; I think we
won't need that as it can be expressable within the Unit concept.

What we might need is the possibility to create subpatches, and if so,
perhaps they should be added to a project's library, as well as
savable in a program-wide library.  I am concerned that if the
subpatches are not saved within the project that it will introduce a
dependency problem when sharing the project or when returning to the
project at a later time.  Perhaps besides the UnitLibraryEditor
dialog, we will need another editor for subpatches.

I think if we have Unit, Constant, and P-Field objects, that could
cover a lot of ground.  Then we will have to cover conditional units
for if/elseif/else conditions, which can be very tricky.  Perhaps
instead of P-Field objects we should have Inputs and Outputs, so that
an Instrument patch can be easily reused as a subpatch.

Lot's to think about!  We may soon have enough to start working though
and perhaps it might be good to just build away a first version and
play with it to test what is good about the design and what is not,
and plan to go through a couple or few designs before it stabilizes
and becomes releasable.

steven

p.s. - FlowGraphInstrument should really be just a thin wrapper for
FlowGraph, which will be reusable amongst other Instrument's.


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

> # I want to make all classes and their resposibilities clear before
> starting to code. I think this thinking process is more important than
> writing the codes. After the specification, the implementations will
> be easier than pondering before the screen. So, this is the
> explanation why I am talking to much but doesn't write any code :-)
>
> # I'm making a chart of classes and their responsibilities:
>
> # Port:
> # This class was not in my project, but after a while I strongly feel
> its necessity.
> # A Port should know wheter it is output or input, to which Opcode
> (and Unit) it belongs, whether a Cable is plugged to it, if yes, to
> which other ports it is connnected. (an output Port may be connected
> to many input ports)
> # This class will be very useful at the end, when it comes to create
> the Csound code. (Furthermore when this ınput/outputs are defined as
> explicit classes, it'll get easier to detect determine wheter mouse
> clicked on it etc.)
> # Every port is related with variable rate type, and a name. The name
> will be the arguments for each opcode in the manual. Different types
> cannot be connected.
>
> # Opcode: (this comes to my mind now)
> # Opcode has one output port (if necessary) and one or more input
> ports (if necessary), has a name and knows to which Unit it belongs.
>
> # Unit:
> # There are two types of units: Expressions and Units.
> # Unit's have an array of Opcodes, has a position, has a name and
> commenti knows either it will get a inline code or a UDO.
> # Expressions have a expressionEvaluator method. According the
> mathematical expression gave to that method it sets proper ports.
>
> # Cable:
> # A Cable knows between which input and output ports it is connected.
>
> # FlowGraphInstrument:
> # It has Units and Cables. Its addCable method is responsible for
> correct connections.
> int addCable(Port input, Port output);
> returns OUT_TO_OUT or similar static int values according to false
> connections, CONNECTED for correct ones etc.
> # and finally the hardest method: public String generateInstrument()
> which, if I understood correctly, generates the Csound instrument code!
>
> # This is the draft structure I think to build. Do you have any
> objections, or properties want to add.
> # next I'll send a mail about the classes of graphical interface.
>
> -ugur-
>

N¬HY޵隊X¬²š'²ŠŞu¼’¦[§‰ÜŒ¨º
ަØk¢è!–ˆŠW¬~Šé®†åzk¶ŠC£ 塧m…éŞÀ@^ǚ­È^ž§zØZ¶f¤zËj·!Šx2¢êå¢â•ë±æ¬É«,º·âža{›å,àHòÔ4¨m¶Ÿÿ±éZ²ëjY‚w­şÇ¥rg–y$‰Ó~7Ù¸Û}8ó§Z´×®6[žšë"qׯzYšŠX§‚X¬´nzk¬‰Ç^½éeŠËl²‹«qç讧zØm¶›?şX¬¶Ë(º·~Šàzw­şX¬¶ÏåŠËbú?n[žšë"qׯz

[Steven Yi]

Strange, I've pasted below what I wrote:

Hi Ugur,

I apologize in advance I'll probably be a little slow to reply to some
of these as it is a big issue to think about as like you I want to get
a good sense of the design before charging into coding, and also
because I think we should try to make it very robust so that the
infrastructure will last a long time.

I was thinking on the way to work today that perhaps expression
objects might not be the way to go.  It makes it complicated and also
adds room for error on the user's part, and I think we need to limit
the possibilities of errors.

I think we also need to make the abstractions very versatile such that
we can create all of the necessary parts from very few abstractions.
I have been thinking quite a bit about how PD and Reaktor work as well
as how Cabel is desgned. We should also look at CSBlocks as it is a
fairly well thought-out flow graph editing program for Csound. We also
need to take into account Csound inherent signal types and graph flow.

So, I am thinking that for Units, we need to be able to accept a-, k-,
i-, and S- type values (S- is a csound5-only string type).  We should
also probably support w- and f- signal types too, but t- rate signals
from CsoundAV I think we should ignore as it is not available in any
other csound.

I think we should have a base Unit type.  Instead of Expression
objects we should have Constant objects, similar to PD's number boxes.
 The constant can output a-, k-, i-, or S- values.  For expressions, I
think you were right in the beginning and it'll be better to do that
as a Unit so that the code is within the Unit and not accessible by
the user, so less chance of error.

I do not quite understand your Opcode class you mention; I think we
won't need that as it can be expressable within the Unit concept.

What we might need is the possibility to create subpatches, and if so,
perhaps they should be added to a project's library, as well as
savable in a program-wide library.  I am concerned that if the
subpatches are not saved within the project that it will introduce a
dependency problem when sharing the project or when returning to the
project at a later time.  Perhaps besides the UnitLibraryEditor
dialog, we will need another editor for subpatches.

I think if we have Unit, Constant, and P-Field objects, that could
cover a lot of ground.  Then we will have to cover conditional units
for if/elseif/else conditions, which can be very tricky.  Perhaps
instead of P-Field objects we should have Inputs and Outputs, so that
an Instrument patch can be easily reused as a subpatch.

Lot's to think about!  We may soon have enough to start working though
and perhaps it might be good to just build away a first version and
play with it to test what is good about the design and what is not,
and plan to go through a couple or few designs before it stabilizes
and becomes releasable.

steven

p.s. - FlowGraphInstrument should really be just a thin wrapper for
FlowGraph, which will be reusable amongst other Instrument's.



On 2/6/06, sokratesla <ugurguney@...> wrote:

> # Your mail was blank. Perhaps an error occured while you sent.
> -ugur
>
> On 2/3/06, Steven Yi <stevenyi@...> wrote:
> >
>
>
> sokratesla  to bluemusic-devel
>   More options   Feb 2 (4 days ago)
>
> # I want to make all classes and their resposibilities clear before
> starting to code. I think this thinking process is more important than
> writing the codes. After the specification, the implementations will
> be easier than pondering before the screen. So, this is the
> explanation why I am talking to much but doesn't write any code :-)
>
> # I'm making a chart of classes and their responsibilities:
>
> # Port:
> # This class was not in my project, but after a while I strongly feel
> its necessity.
> # A Port should know wheter it is output or input, to which Opcode
> (and Unit) it belongs, whether a Cable is plugged to it, if yes, to
> which other ports it is connnected. (an output Port may be connected
> to many input ports)
> # This class will be very useful at the end, when it comes to create
> the Csound code. (Furthermore when this ınput/outputs are defined as
> explicit classes, it'll get easier to detect determine wheter mouse
> clicked on it etc.)
> # Every port is related with variable rate type, and a name. The name
> will be the arguments for each opcode in the manual. Different types
> cannot be connected.
>
> # Opcode: (this comes to my mind now)
> # Opcode has one output port (if necessary) and one or more input
> ports (if necessary), has a name and knows to which Unit it belongs.
>
> # Unit:
> # There are two types of units: Expressions and Units.
> # Unit's have an array of Opcodes, has a position, has a name and
> commenti knows either it will get a inline code or a UDO.
> # Expressions have a expressionEvaluator method. According the
> mathematical expression gave to that method it sets proper ports.
>
> # Cable:
> # A Cable knows between which input and output ports it is connected.
>
> # FlowGraphInstrument:
> # It has Units and Cables. Its addCable method is responsible for
> correct connections.
> int addCable(Port input, Port output);
> returns OUT_TO_OUT or similar static int values according to false
> connections, CONNECTED for correct ones etc.
> # and finally the hardest method: public String generateInstrument()
> which, if I understood correctly, generates the Csound instrument code!
>
> # This is the draft structure I think to build. Do you have any
> objections, or properties want to add.
> # next I'll send a mail about the classes of graphical interface.
>
> -ugur-
>

N¬HY޵隊X¬²š'²ŠŞu¼’¦[§‰ÜŒ¨º
ަØk¢è!–ˆŠW¬~Šé®†åzk¶ŠC£ 塧m…éŞÀ@^ǚ­È^ž§zØZ¶f¤zËj·!Šx2¢êå¢â•ë±æ¬É«,º·âža{›å,àHòÔ4¨m¶Ÿÿ±éZ²ëjY‚w­şÇ¥rg–y$‰Ó~7Ù¸Û}8ó§Z´×®6[žšë"qׯzYšŠX§‚X¬´nzk¬‰Ç^½éeŠËl²‹«qç讧zØm¶›?şX¬¶Ë(º·~Šàzw­şX¬¶ÏåŠËbú?n[žšë"qׯz

[Ugur Guney]

On 2/6/06, Steven Yi <stevenyi@...> wrote:
> I was thinking on the way to work today that perhaps expression
> objects might not be the way to go.  It makes it complicated and also
> adds room for error on the user's part, and I think we need to limit
> the possibilities of errors.

> I think we should have a base Unit type.  Instead of Expression
> objects we should have Constant objects, similar to PD's number boxes.
>  The constant can output a-, k-, i-, or S- values.  For expressions, I
> think you were right in the beginning and it'll be better to do that
> as a Unit so that the code is within the Unit and not accessible by
> the user, so less chance of error.

# We've exchanged our ideas :-) I liked the idea of having an
expression object. As you know, at start, I considered the Unit as an
editable object too. But after making an Unit Library this will be
unnecessary, because one will have all opcodes at hand, and can write
its own Units.
# However, expressions are somewhat different. Its not possible to
prepare all mathematical expressions :-) of course.
# Two solutions have been mentioned and both of them can be applied. I
think, the one of the superiorities of Csound over other moduler music
softwares is its basis on text. Writing mathematical expressions with
keyboard, by typing, is easier than creating constant units, operator
units and connecting them with cables.
# We can prepare both an expression unit, and math units. The user can
choose s/he's own preference.
# And to reducing possible errors, expression unit can be constructed
so that it gets disabled when an uncorrect expression is written.
(like the disabled Units in the .jar file I first sent.)
# Certainly, we need a parser for the expression object. I can try to
write one, or we can you the parser you want to implement in the
Mixer.

> I think we also need to make the abstractions very versatile such that
> we can create all of the necessary parts from very few abstractions.
> I have been thinking quite a bit about how PD and Reaktor work as well
> as how Cabel is desgned. We should also look at CSBlocks as it is a
> fairly well thought-out flow graph editing program for Csound. We also
> need to take into account Csound inherent signal types and graph flow.

# Oww... When I started my Java project, I supposed that I'm the only
one who wants to write an GUI for Csound instruments. Then I heared
Cabel. And today I learned CSBlocks, and am suspicious about the
existenz of other interfaces :-) I feel very useless :-(

> So, I am thinking that for Units, we need to be able to accept a-, k-,
> i-, and S- type values (S- is a csound5-only string type).  We should
> also probably support w- and f- signal types too, but t- rate signals
> from CsoundAV I think we should ignore as it is not available in any
> other csound.

# Ok, Unit Library Editor should control wheter the arguments starts
with a, k, i, S, w or f. And these will be the types of a Port.

-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

[Steven Yi]

Hi Ugur,

> # We've exchanged our ideas :-) I liked the idea of having an
> expression object. As you know, at start, I considered the Unit as an
> editable object too. But after making an Unit Library this will be
> unnecessary, because one will have all opcodes at hand, and can write
> its own Units.
> # However, expressions are somewhat different. Its not possible to
> prepare all mathematical expressions :-) of course.
> # Two solutions have been mentioned and both of them can be applied. I
> think, the one of the superiorities of Csound over other moduler music
> softwares is its basis on text. Writing mathematical expressions with
> keyboard, by typing, is easier than creating constant units, operator
> units and connecting them with cables.
> # We can prepare both an expression unit, and math units. The user can
> choose s/he's own preference.
> # And to reducing possible errors, expression unit can be constructed
> so that it gets disabled when an uncorrect expression is written.
> (like the disabled Units in the .jar file I first sent.)
> # Certainly, we need a parser for the expression object. I can try to
> write one, or we can you the parser you want to implement in the
> Mixer.

I think we can do an expression object that works like this (and
requires no expression parser! =) ):

-the expression object can be any code that is typed, something like this:

(ival *45) + (kenv * 4)

-the above, when the editing is done and the user presses enter, can
be parsed to read what are the variables, then create input boxes
depending on the values found.  The output value rate can be intuited
from the inputs (i.e. the case above, output would be k-rate because
the expression is krate).

-when the above goes to compile, the values can be replaced with the
i- and k- values from the cables that hook up to it, and the following
can be generated in the orch code:

ktemp = (ival *45) + (kenv * 4)

and the output value is the ktemp.  That should work for expression
ideas I think.


> # Oww... When I started my Java project, I supposed that I'm the only
> one who wants to write an GUI for Csound instruments. Then I heared
> Cabel. And today I learned CSBlocks, and am suspicious about the
> existenz of other interfaces :-) I feel very useless :-(

Hardly!  There was another modular java project donated to work with
blue already, JavaOrc, but it was not easy for me to modify so I never
got around to using it really (it is in the blue CVS in the plugins
module, by the way, and may have good ideas to use). CSBlocks and
Cabel both are not in Java and therefore unable to get hooked into
blue; they are useful in themselves, but really for blue, it will be a
very useful thing to have this in Java and to work within the blue
environment.  So I think your project will be very valuable and
useful. =)


> # Ok, Unit Library Editor should control wheter the arguments starts
> with a, k, i, S, w or f. And these will be the types of a Port.

Sounds good!

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