Re: FlowGraph - Opcodes & the algorithm to generate Csound code

[Ugur Guney]

# I'm thinking about the final algorithm which generates the Csound
code. If we determine it, it gets easier to set our classes.
# The algorithm consists of two main parts: First "naming the Ports".
Namely, all Ports have similar names "asig", "aout", "kenv", "ival"
etc. First part will change them "a1", "a2", "a3", "k57" etc. (or if
we want to struggle more, asig1, asig2, aout1, aout2...)
# FlowGraph is responsible for the implementaion of this algorithm.
# It'll use a recursive function for this purpose.
# All Units are in an ArrayList in the FlowGraph. It starts to control
from to first Unit wheter it is "checked". (checked means all of the
Ports of this Unit is "named") If it isn't checked, the function looks
to all output Ports that are connected to this Units input Ports. If
all of them are named, it'll name the input Ports and check the Unit.
# But if some of the output Ports that are connected to this Units
input Ports are not named, the function will be applied to the owner
Units of that output Ports. (here is the recursion, if I'm using the
term correctly) So, the function go upwards through the Units until it
finds a Unit of which input Ports are named, or which has no input
Ports.
# After all recursive functions are finished, FlowGraph turns to the
first Unit in the ArrayList again and controls all of them whether
they are checked. If it come across an unchecked Unit applies that
recursive function on it and return to the first Unit. First part
stops when the counter reaches to the end of Unit ArrayList.
# So, all Ports are named with proper names. The remaining job is
constructing the code from the contents of units in proper order.
# I think, cutting the code into parts by using Port and Opcode
classes will help at this part.
# "Naming part" will change the names of the Ports. I suppose, it gets
harder when a Unit have its piece of code as a String. If there are
more than one row, namely more opcodes, in its code some of which have
same input argument names, renaming them will be harder. Which input
Port is related with which argument? This is the difficulty that I
faced one day before submitting my Java project :-) Units had have
only code Strings (no Ports, no Opcodes) and after every editing they
have to constructing their IO's again. But then I realized that when I
give the possibility of having more than one opcodes it isn't possible
to reconstruct the code with appropriate variable names.
# For the second part goes in reverse direction of the first part.
(from above to downwards) It searches for a Unit which have no inputs,
or constant inputs, or p-field initializations, and starts from that
Unit. Write its code first, and check it. (now, checking means that,
"its code is written, don't bother with it again") Then searchs for
most above, unchecked Unit, and writes down its code... Until all
Units are checked.
# If we know explicitly which Opcode have which Ports, the
reconstruction of the code will be extremely easy.

# I didn't have thought about sub-patches. But they are standarts in
every Flow Chart music software. We have to implement them :-)

-ugur-

On 2/8/06, Steven Yi <stevenyi@...> wrote:

> HI Ugur,
>
> It still seems to me that it is unecessary, but it might be how I am
> understanding the idea and what you have in mind may be different. To
> me, the Unit class should be text Csound code whose inputs and outputs
> are read either from the code or explicitly set using an editor.
> There doesn't seem to be a requirement for a sub-object for opcodes in
> this.  When the patch is compiled, it shouldn't need to know the
> contents of the Unit, only how to take the inputs and outputs and hook
> them up, so no need to know anything about the opcodes used in it. If
> anything, I think the FlowGraph class could have sub-FlowGraph's, in
> the same way a PD patch can be standalone or be a subpatch to another
> patch.
>
> Am I misunderstanding what you have in mind?
>
> steven
>
> On 2/7/06, sokratesla <ugurguney@...> wrote:
> > On 2/7/06, Steven Yi <stevenyi@...> wrote:
> > > Hi Ugur and all,
> > >
> > > I'm checking out the code that's going into CVS but am still confused
> > > about the need for an Opcode class.  I think the Unit class should be
> > > enough to handle the abstraction of a single opcode or group of
> > > orchestra code.
> > > steven
> >
> > # Instead of having an array for opcode names, and an array of Ports
> > in the Unit, and finding out a way to link the opcodes with the
> > related opcode, I think, having an Opcode class which knows its output
> > and inputs ports and having a Unit which have an array of Opcodes is
> > easier to implement? Its very unnecessary when the Unit have only one
> > opcode but I thought that makes the life easier when there are more
> > than one opcodes, which may use the same Port etc.
> > # I surmised that it makes the structure more clear. Do you think that
> > this classification unnecessary?
> > -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,

Just a quick reply right now to be followed with a longer reply: I
implemented a system in the never-finished CeciliaModule that parsed
all global variables and reassigned new unique variable names.  This
type of thing might be easier than parsing into separate opcodes,
simply looking for variables (i.e. code that starts with i-, k-, a-,
S-, w-, and f-) and if found, register it with a VariablesManager
class to get a unique variable name, and then text replace within the
unit.  I still don't think an Opcode class is necessary, and my hunch
is that we also won't have to parse down to the Opcode level and
recreate the whole graph instrument graph at that atomic a level.
What we will need to parse the graph of the objects at the Unit level,
and in generating the code, making sure all variables are unique, so
that if you use 5 copies of the same unit, they don't interfere with
each other.

(Which reminds me, I wrote a patch system some 4 or 5 years ago that
did work, but was very simplistic.  I'll try digging out that code to
see if there is anything there to reuse.)

Juast as a note: I am getting close to hooking up the basic Mixer
system (no effects or sends; probably tonight) and after some testing
of that, will look to put out a release and then will refocus to split
time between the Effects Editor and hooking that into the Mixer, and
then also will be spending much more time with the FlowGraph.

I'll try to reply more later when I have more time(probably later tonight)!
steven

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

> # I'm thinking about the final algorithm which generates the Csound
> code. If we determine it, it gets easier to set our classes.
> # The algorithm consists of two main parts: First "naming the Ports".
> Namely, all Ports have similar names "asig", "aout", "kenv", "ival"
> etc. First part will change them "a1", "a2", "a3", "k57" etc. (or if
> we want to struggle more, asig1, asig2, aout1, aout2...)
> # FlowGraph is responsible for the implementaion of this algorithm.
> # It'll use a recursive function for this purpose.
> # All Units are in an ArrayList in the FlowGraph. It starts to control
> from to first Unit wheter it is "checked". (checked means all of the
> Ports of this Unit is "named") If it isn't checked, the function looks
> to all output Ports that are connected to this Units input Ports. If
> all of them are named, it'll name the input Ports and check the Unit.
> # But if some of the output Ports that are connected to this Units
> input Ports are not named, the function will be applied to the owner
> Units of that output Ports. (here is the recursion, if I'm using the
> term correctly) So, the function go upwards through the Units until it
> finds a Unit of which input Ports are named, or which has no input
> Ports.
> # After all recursive functions are finished, FlowGraph turns to the
> first Unit in the ArrayList again and controls all of them whether
> they are checked. If it come across an unchecked Unit applies that
> recursive function on it and return to the first Unit. First part
> stops when the counter reaches to the end of Unit ArrayList.
> # So, all Ports are named with proper names. The remaining job is
> constructing the code from the contents of units in proper order.
> # I think, cutting the code into parts by using Port and Opcode
> classes will help at this part.
> # "Naming part" will change the names of the Ports. I suppose, it gets
> harder when a Unit have its piece of code as a String. If there are
> more than one row, namely more opcodes, in its code some of which have
> same input argument names, renaming them will be harder. Which input
> Port is related with which argument? This is the difficulty that I
> faced one day before submitting my Java project :-) Units had have
> only code Strings (no Ports, no Opcodes) and after every editing they
> have to constructing their IO's again. But then I realized that when I
> give the possibility of having more than one opcodes it isn't possible
> to reconstruct the code with appropriate variable names.
> # For the second part goes in reverse direction of the first part.
> (from above to downwards) It searches for a Unit which have no inputs,
> or constant inputs, or p-field initializations, and starts from that
> Unit. Write its code first, and check it. (now, checking means that,
> "its code is written, don't bother with it again") Then searchs for
> most above, unchecked Unit, and writes down its code... Until all
> Units are checked.
> # If we know explicitly which Opcode have which Ports, the
> reconstruction of the code will be extremely easy.
>
> # I didn't have thought about sub-patches. But they are standarts in
> every Flow Chart music software. We have to implement them :-)
>
> -ugur-
>
> On 2/8/06, Steven Yi <stevenyi@...> wrote:
> > HI Ugur,
> >
> > It still seems to me that it is unecessary, but it might be how I am
> > understanding the idea and what you have in mind may be different. To
> > me, the Unit class should be text Csound code whose inputs and outputs
> > are read either from the code or explicitly set using an editor.
> > There doesn't seem to be a requirement for a sub-object for opcodes in
> > this.  When the patch is compiled, it shouldn't need to know the
> > contents of the Unit, only how to take the inputs and outputs and hook
> > them up, so no need to know anything about the opcodes used in it. If
> > anything, I think the FlowGraph class could have sub-FlowGraph's, in
> > the same way a PD patch can be standalone or be a subpatch to another
> > patch.
> >
> > Am I misunderstanding what you have in mind?
> >
> > steven
> >
> > On 2/7/06, sokratesla <ugurguney@...> wrote:
> > > On 2/7/06, Steven Yi <stevenyi@...> wrote:
> > > > Hi Ugur and all,
> > > >
> > > > I'm checking out the code that's going into CVS but am still confused
> > > > about the need for an Opcode class.  I think the Unit class should be
> > > > enough to handle the abstraction of a single opcode or group of
> > > > orchestra code.
> > > > steven
> > >
> > > # Instead of having an array for opcode names, and an array of Ports
> > > in the Unit, and finding out a way to link the opcodes with the
> > > related opcode, I think, having an Opcode class which knows its output
> > > and inputs ports and having a Unit which have an array of Opcodes is
> > > easier to implement? Its very unnecessary when the Unit have only one
> > > opcode but I thought that makes the life easier when there are more
> > > than one opcodes, which may use the same Port etc.
> > > # I surmised that it makes the structure more clear. Do you think that
> > > this classification unnecessary?
> > > -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?cmdlnk&kid3432&bid#0486&dat1642
> _______________________________________________
> 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

[Steven Yi]

Hi Ugur,

I worked on a set of ideas and classes and committed them in the
blue.orchestra.flowgraph.test package.  I am running into some issues
that I think are already solved by you and also in Cabel, and also
apparently by myself 5 years ago too!  (I found my old macro patch
program and put it on http://www.kunstmusik.com/macroPatch.zip if you
are interested to see it; the code is ugly and old, but works!).

I also played with Cabel today and was once again impressed with it.
I think the Port class is important to have some meta data attached to
it, which cabel does, and that includes minimum value, maximum value,
default value,  and description.  In Cabel, all ports start off with
their defaults; you can edit the value for the port by double clicking
the box and then a group of sliders show up for editing the value of
the port.  If you connect something to that port, that property become
non-editable and the default isn't used.  I think this is a very good
thing to implement.

We also need to have as part of the Unit Editor the ability to
explicitly designate Input Ports and output Ports.  For those, I am
thinking of two table editors, so you can add and edit their type and
properties.

Also, I think tonight that it is import to include a port that can
accept multiple-inputs.  It would automatically add an extra visual
port beyond the number already connected, and if you add a connection
an extra visual port is added.  The values from the port then should
generate a comma separated list to be used in the code.  The reason
for this is to have something like a generic sum Unit, where you can
add as many cables and the code would compile out to:

aout   sum a1,a2,a3,a4,a5,a6

This kind of variable arg list I think will be handy, but will require
a mapping function from visual ports to actual ports.  Without this
support though, we'll end up having something like Music V's AD2, AD3,
AD4 unit generates for any opcode that can take a variable number of
inputs, which I think would be painful.

I'm going to look at the MacroPatch code myself and continue to study
cabel and the code you have.  I think we should proceed by hammering
out the Model classes and creating test cases that use the model
classes directly; if we know that works, then coding the User
Interface won't be difficult afterwards.

steven

p.s. - Another nice thing about Cabel's design decision to wrap
everything in UDO's is that there is no worry of namespace clashes of
variable names as they are all encapsulated.  I think we can work
around it though with a Unique ID system.


On 2/8/06, Steven Yi <stevenyi@...> wrote:

> Hi Ugur,
>
> Just a quick reply right now to be followed with a longer reply: I
> implemented a system in the never-finished CeciliaModule that parsed
> all global variables and reassigned new unique variable names.  This
> type of thing might be easier than parsing into separate opcodes,
> simply looking for variables (i.e. code that starts with i-, k-, a-,
> S-, w-, and f-) and if found, register it with a VariablesManager
> class to get a unique variable name, and then text replace within the
> unit.  I still don't think an Opcode class is necessary, and my hunch
> is that we also won't have to parse down to the Opcode level and
> recreate the whole graph instrument graph at that atomic a level.
> What we will need to parse the graph of the objects at the Unit level,
> and in generating the code, making sure all variables are unique, so
> that if you use 5 copies of the same unit, they don't interfere with
> each other.
>
> (Which reminds me, I wrote a patch system some 4 or 5 years ago that
> did work, but was very simplistic.  I'll try digging out that code to
> see if there is anything there to reuse.)
>
> Juast as a note: I am getting close to hooking up the basic Mixer
> system (no effects or sends; probably tonight) and after some testing
> of that, will look to put out a release and then will refocus to split
> time between the Effects Editor and hooking that into the Mixer, and
> then also will be spending much more time with the FlowGraph.
>
> I'll try to reply more later when I have more time(probably later tonight)!
> steven
>
> On 2/8/06, sokratesla <ugurguney@...> wrote:
> > # I'm thinking about the final algorithm which generates the Csound
> > code. If we determine it, it gets easier to set our classes.
> > # The algorithm consists of two main parts: First "naming the Ports".
> > Namely, all Ports have similar names "asig", "aout", "kenv", "ival"
> > etc. First part will change them "a1", "a2", "a3", "k57" etc. (or if
> > we want to struggle more, asig1, asig2, aout1, aout2...)
> > # FlowGraph is responsible for the implementaion of this algorithm.
> > # It'll use a recursive function for this purpose.
> > # All Units are in an ArrayList in the FlowGraph. It starts to control
> > from to first Unit wheter it is "checked". (checked means all of the
> > Ports of this Unit is "named") If it isn't checked, the function looks
> > to all output Ports that are connected to this Units input Ports. If
> > all of them are named, it'll name the input Ports and check the Unit.
> > # But if some of the output Ports that are connected to this Units
> > input Ports are not named, the function will be applied to the owner
> > Units of that output Ports. (here is the recursion, if I'm using the
> > term correctly) So, the function go upwards through the Units until it
> > finds a Unit of which input Ports are named, or which has no input
> > Ports.
> > # After all recursive functions are finished, FlowGraph turns to the
> > first Unit in the ArrayList again and controls all of them whether
> > they are checked. If it come across an unchecked Unit applies that
> > recursive function on it and return to the first Unit. First part
> > stops when the counter reaches to the end of Unit ArrayList.
> > # So, all Ports are named with proper names. The remaining job is
> > constructing the code from the contents of units in proper order.
> > # I think, cutting the code into parts by using Port and Opcode
> > classes will help at this part.
> > # "Naming part" will change the names of the Ports. I suppose, it gets
> > harder when a Unit have its piece of code as a String. If there are
> > more than one row, namely more opcodes, in its code some of which have
> > same input argument names, renaming them will be harder. Which input
> > Port is related with which argument? This is the difficulty that I
> > faced one day before submitting my Java project :-) Units had have
> > only code Strings (no Ports, no Opcodes) and after every editing they
> > have to constructing their IO's again. But then I realized that when I
> > give the possibility of having more than one opcodes it isn't possible
> > to reconstruct the code with appropriate variable names.
> > # For the second part goes in reverse direction of the first part.
> > (from above to downwards) It searches for a Unit which have no inputs,
> > or constant inputs, or p-field initializations, and starts from that
> > Unit. Write its code first, and check it. (now, checking means that,
> > "its code is written, don't bother with it again") Then searchs for
> > most above, unchecked Unit, and writes down its code... Until all
> > Units are checked.
> > # If we know explicitly which Opcode have which Ports, the
> > reconstruction of the code will be extremely easy.
> >
> > # I didn't have thought about sub-patches. But they are standarts in
> > every Flow Chart music software. We have to implement them :-)
> >
> > -ugur-
> >
> > On 2/8/06, Steven Yi <stevenyi@...> wrote:
> > > HI Ugur,
> > >
> > > It still seems to me that it is unecessary, but it might be how I am
> > > understanding the idea and what you have in mind may be different. To
> > > me, the Unit class should be text Csound code whose inputs and outputs
> > > are read either from the code or explicitly set using an editor.
> > > There doesn't seem to be a requirement for a sub-object for opcodes in
> > > this.  When the patch is compiled, it shouldn't need to know the
> > > contents of the Unit, only how to take the inputs and outputs and hook
> > > them up, so no need to know anything about the opcodes used in it. If
> > > anything, I think the FlowGraph class could have sub-FlowGraph's, in
> > > the same way a PD patch can be standalone or be a subpatch to another
> > > patch.
> > >
> > > Am I misunderstanding what you have in mind?
> > >
> > > steven
> > >
> > > On 2/7/06, sokratesla <ugurguney@...> wrote:
> > > > On 2/7/06, Steven Yi <stevenyi@...> wrote:
> > > > > Hi Ugur and all,
> > > > >
> > > > > I'm checking out the code that's going into CVS but am still confused
> > > > > about the need for an Opcode class.  I think the Unit class should be
> > > > > enough to handle the abstraction of a single opcode or group of
> > > > > orchestra code.
> > > > > steven
> > > >
> > > > # Instead of having an array for opcode names, and an array of Ports
> > > > in the Unit, and finding out a way to link the opcodes with the
> > > > related opcode, I think, having an Opcode class which knows its output
> > > > and inputs ports and having a Unit which have an array of Opcodes is
> > > > easier to implement? Its very unnecessary when the Unit have only one
> > > > opcode but I thought that makes the life easier when there are more
> > > > than one opcodes, which may use the same Port etc.
> > > > # I surmised that it makes the structure more clear. Do you think that
> > > > this classification unnecessary?
> > > > -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?cmdlnk&kid3432&bid#0486&dat1642
> > _______________________________________________
> > 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