Is there a mechanism to find out what gen routine was used to create a
particular table. I took a look at the FUNC structure but couldn't see
anything?

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

If you are displaying and editing the table it can be useful to know
what GEN routine was used to create it. Otherwise you could end up
drawing straight lines in a table whose gen routine is used to create
exponential curves. If I could query the GEN number I could ensure
that my tables behave the same way as Csound's. So if one displays a
gen07 table I know that it's straight lines all the way. But I can't
tell it's gen anything from looking at the values.

On 16 April 2014 15:00,   wrote:
> Not sure this is a meaningful concept.  A table contains values, and
> that is all
>
> Quoting Andres Cabrera :
>
>> I guess it could be added if it's not there, but there might be additional
>> changes after creation using opcodes or the API.
>>
>> Cheers,
>> Andrés
>>
>>
>> On Wed, Apr 16, 2014 at 6:42 AM, Rory Walsh  wrote:
>>
>>> Is there a mechanism to find out what gen routine was used to create a
>>> particular table. I took a look at the FUNC structure but couldn't see
>>> anything?
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Does anyone else have any thoughts on this? I could of course parse
the Csound text myself but this seems a bit extreme..

On 16 April 2014 16:19, Rory Walsh  wrote:
> If you are displaying and editing the table it can be useful to know
> what GEN routine was used to create it. Otherwise you could end up
> drawing straight lines in a table whose gen routine is used to create
> exponential curves. If I could query the GEN number I could ensure
> that my tables behave the same way as Csound's. So if one displays a
> gen07 table I know that it's straight lines all the way. But I can't
> tell it's gen anything from looking at the values.
>
> On 16 April 2014 15:00,   wrote:
>> Not sure this is a meaningful concept.  A table contains values, and
>> that is all
>>
>> Quoting Andres Cabrera :
>>
>>> I guess it could be added if it's not there, but there might be additional
>>> changes after creation using opcodes or the API.
>>>
>>> Cheers,
>>> Andrés
>>>
>>>
>>> On Wed, Apr 16, 2014 at 6:42 AM, Rory Walsh  wrote:
>>>
>>>> Is there a mechanism to find out what gen routine was used to create a
>>>> particular table. I took a look at the FUNC structure but couldn't see
>>>> anything?
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/NeoTech
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

That's more or less how I'm doing it at the moment but of course, in
my case, it forces users to create tables in the score(so much easier
to parse there). I would really like a generic solution to this but
it's looking more and more like I'll have to create some kind of
Cabbage table opcode. This would be a terrible solution IMO. I'm aware
that at any stage after creation a table could be modified so that the
gen line used to create it is redundant, but in the context of what
I'm trying to do this wouldn't be a problem. I just need to know what
was used to set up the table in the first place. I'm not talking so
much about traditional table editing whereby a user can drag and drop
a handle. I'm interested in abstracting the gen routines to offer a
new type of envelope editing.

On 17 April 2014 18:52, Andres Cabrera  wrote:
> It seems messy to me as there is no guarantee that the data in the table
> actually corresponds to the gen line that would be contained in it. I think
> it is better to handle this within the front end.
>
> If you only allow this type of editing for tables created in a particular
> way, then you can store the information cleanly yourself without having to
> do any parsing of the file (which can get complicated if you support all the
> mechanisms ftgen, ftgentmp, f, socreline, etc.)
>
> Cheers,
> Andrés
>
>
> On Thu, Apr 17, 2014 at 9:48 AM, Rory Walsh  wrote:
>>
>> Does anyone else have any thoughts on this? I could of course parse
>> the Csound text myself but this seems a bit extreme..
>>
>> On 16 April 2014 16:19, Rory Walsh  wrote:
>> > If you are displaying and editing the table it can be useful to know
>> > what GEN routine was used to create it. Otherwise you could end up
>> > drawing straight lines in a table whose gen routine is used to create
>> > exponential curves. If I could query the GEN number I could ensure
>> > that my tables behave the same way as Csound's. So if one displays a
>> > gen07 table I know that it's straight lines all the way. But I can't
>> > tell it's gen anything from looking at the values.
>> >
>> > On 16 April 2014 15:00,   wrote:
>> >> Not sure this is a meaningful concept.  A table contains values, and
>> >> that is all
>> >>
>> >> Quoting Andres Cabrera :
>> >>
>> >>> I guess it could be added if it's not there, but there might be
>> >>> additional
>> >>> changes after creation using opcodes or the API.
>> >>>
>> >>> Cheers,
>> >>> Andrés
>> >>>
>> >>>
>> >>> On Wed, Apr 16, 2014 at 6:42 AM, Rory Walsh  wrote:
>> >>>
>> >>>> Is there a mechanism to find out what gen routine was used to create
>> >>>> a
>> >>>> particular table. I took a look at the FUNC structure but couldn't
>> >>>> see
>> >>>> anything?
>> >>>>
>> >>>>
>> >>>>
>> >>>> ------------------------------------------------------------------------------
>> >>>> Learn Graph Databases - Download FREE O'Reilly Book
>> >>>> "Graph Databases" is the definitive new guide to graph databases and
>> >>>> their
>> >>>> applications. Written by three acclaimed leaders in the field,
>> >>>> this first edition is now available. Download your free book today!
>> >>>> http://p.sf.net/sfu/NeoTech
>> >>>> _______________________________________________
>> >>>> Csound-devel mailing list
>> >>>> Csound-devel@lists.sourceforge.net
>> >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>>>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Learn Graph Databases - Download FREE O'Reilly Book
>> >> "Graph Databases" is the definitive new guide to graph databases and
>> >> their
>> >> applications. Written by three acclaimed leaders in the field,
>> >> this first edition is now available. Download your free book today!
>> >> http://p.sf.net/sfu/NeoTech
>> >> _______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

That would be perfect for my needs. And yes, the last thing I want is
to introduce Cabbage only orchestra features. I'm still trying to get
my head around the inner workings of Csound, but am I right in
assuming that in any one of the gen functions found in fgens.c I would
need to access the EVTBLK member of the FGDATA structure to find out
the gen routine? I would then assign that, and the entire score
statement to two new members of FUNC so that it can be accessed via
csound->flist[]?

On 17 April 2014 19:51, Andres Cabrera  wrote:
> I guess there could be a field in the table structure to hold the original
> data for creation. I would agree that having something Cabbage specific
> would be a bad idea. Fragmentation of the language is certainly not good.
>
> Cheers,
> Andrés
>
>
> On Thu, Apr 17, 2014 at 10:10 AM, Rory Walsh  wrote:
>>
>> That's more or less how I'm doing it at the moment but of course, in
>> my case, it forces users to create tables in the score(so much easier
>> to parse there). I would really like a generic solution to this but
>> it's looking more and more like I'll have to create some kind of
>> Cabbage table opcode. This would be a terrible solution IMO. I'm aware
>> that at any stage after creation a table could be modified so that the
>> gen line used to create it is redundant, but in the context of what
>> I'm trying to do this wouldn't be a problem. I just need to know what
>> was used to set up the table in the first place. I'm not talking so
>> much about traditional table editing whereby a user can drag and drop
>> a handle. I'm interested in abstracting the gen routines to offer a
>> new type of envelope editing.
>>
>> On 17 April 2014 18:52, Andres Cabrera  wrote:
>> > It seems messy to me as there is no guarantee that the data in the table
>> > actually corresponds to the gen line that would be contained in it. I
>> > think
>> > it is better to handle this within the front end.
>> >
>> > If you only allow this type of editing for tables created in a
>> > particular
>> > way, then you can store the information cleanly yourself without having
>> > to
>> > do any parsing of the file (which can get complicated if you support all
>> > the
>> > mechanisms ftgen, ftgentmp, f, socreline, etc.)
>> >
>> > Cheers,
>> > Andrés
>> >
>> >
>> > On Thu, Apr 17, 2014 at 9:48 AM, Rory Walsh  wrote:
>> >>
>> >> Does anyone else have any thoughts on this? I could of course parse
>> >> the Csound text myself but this seems a bit extreme..
>> >>
>> >> On 16 April 2014 16:19, Rory Walsh  wrote:
>> >> > If you are displaying and editing the table it can be useful to know
>> >> > what GEN routine was used to create it. Otherwise you could end up
>> >> > drawing straight lines in a table whose gen routine is used to create
>> >> > exponential curves. If I could query the GEN number I could ensure
>> >> > that my tables behave the same way as Csound's. So if one displays a
>> >> > gen07 table I know that it's straight lines all the way. But I can't
>> >> > tell it's gen anything from looking at the values.
>> >> >
>> >> > On 16 April 2014 15:00,   wrote:
>> >> >> Not sure this is a meaningful concept.  A table contains values, and
>> >> >> that is all
>> >> >>
>> >> >> Quoting Andres Cabrera :
>> >> >>
>> >> >>> I guess it could be added if it's not there, but there might be
>> >> >>> additional
>> >> >>> changes after creation using opcodes or the API.
>> >> >>>
>> >> >>> Cheers,
>> >> >>> Andrés
>> >> >>>
>> >> >>>
>> >> >>> On Wed, Apr 16, 2014 at 6:42 AM, Rory Walsh 
>> >> >>> wrote:
>> >> >>>
>> >> >>>> Is there a mechanism to find out what gen routine was used to
>> >> >>>> create
>> >> >>>> a
>> >> >>>> particular table. I took a look at the FUNC structure but couldn't
>> >> >>>> see
>> >> >>>> anything?
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> ------------------------------------------------------------------------------
>> >> >>>> Learn Graph Databases - Download FREE O'Reilly Book
>> >> >>>> "Graph Databases" is the definitive new guide to graph databases
>> >> >>>> and
>> >> >>>> their
>> >> >>>> applications. Written by three acclaimed leaders in the field,
>> >> >>>> this first edition is now available. Download your free book
>> >> >>>> today!
>> >> >>>> http://p.sf.net/sfu/NeoTech
>> >> >>>> _______________________________________________
>> >> >>>> Csound-devel mailing list
>> >> >>>> Csound-devel@lists.sourceforge.net
>> >> >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >> >>>>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> ------------------------------------------------------------------------------
>> >> >> Learn Graph Databases - Download FREE O'Reilly Book
>> >> >> "Graph Databases" is the definitive new guide to graph databases and
>> >> >> their
>> >> >> applications. Written by three acclaimed leaders in the field,
>> >> >> this first edition is now available. Download your free book today!
>> >> >> http://p.sf.net/sfu/NeoTech
>> >> >> _______________________________________________
>> >> >> Csound-devel mailing list
>> >> >> Csound-devel@lists.sourceforge.net
>> >> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Learn Graph Databases - Download FREE O'Reilly Book
>> >> "Graph Databases" is the definitive new guide to graph databases and
>> >> their
>> >> applications. Written by three acclaimed leaders in the field,
>> >> this first edition is now available. Download your free book today!
>> >> http://p.sf.net/sfu/NeoTech
>> >> _______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Learn Graph Databases - Download FREE O'Reilly Book
>> > "Graph Databases" is the definitive new guide to graph databases and
>> > their
>> > applications. Written by three acclaimed leaders in the field,
>> > this first edition is now available. Download your free book today!
>> > http://p.sf.net/sfu/NeoTech
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I really dislike the idea of modifying Csound for this.  What exactly
are you trying to do that couldn't be done by tracking things in your
host?

On Thu, Apr 17, 2014 at 2:23 PM, Rory Walsh  wrote:
> That would be perfect for my needs. And yes, the last thing I want is
> to introduce Cabbage only orchestra features. I'm still trying to get
> my head around the inner workings of Csound, but am I right in
> assuming that in any one of the gen functions found in fgens.c I would
> need to access the EVTBLK member of the FGDATA structure to find out
> the gen routine? I would then assign that, and the entire score
> statement to two new members of FUNC so that it can be accessed via
> csound->flist[]?
>
> On 17 April 2014 19:51, Andres Cabrera  wrote:
>> I guess there could be a field in the table structure to hold the original
>> data for creation. I would agree that having something Cabbage specific
>> would be a bad idea. Fragmentation of the language is certainly not good.
>>
>> Cheers,
>> Andrés
>>
>>
>> On Thu, Apr 17, 2014 at 10:10 AM, Rory Walsh  wrote:
>>>
>>> That's more or less how I'm doing it at the moment but of course, in
>>> my case, it forces users to create tables in the score(so much easier
>>> to parse there). I would really like a generic solution to this but
>>> it's looking more and more like I'll have to create some kind of
>>> Cabbage table opcode. This would be a terrible solution IMO. I'm aware
>>> that at any stage after creation a table could be modified so that the
>>> gen line used to create it is redundant, but in the context of what
>>> I'm trying to do this wouldn't be a problem. I just need to know what
>>> was used to set up the table in the first place. I'm not talking so
>>> much about traditional table editing whereby a user can drag and drop
>>> a handle. I'm interested in abstracting the gen routines to offer a
>>> new type of envelope editing.
>>>
>>> On 17 April 2014 18:52, Andres Cabrera  wrote:
>>> > It seems messy to me as there is no guarantee that the data in the table
>>> > actually corresponds to the gen line that would be contained in it. I
>>> > think
>>> > it is better to handle this within the front end.
>>> >
>>> > If you only allow this type of editing for tables created in a
>>> > particular
>>> > way, then you can store the information cleanly yourself without having
>>> > to
>>> > do any parsing of the file (which can get complicated if you support all
>>> > the
>>> > mechanisms ftgen, ftgentmp, f, socreline, etc.)
>>> >
>>> > Cheers,
>>> > Andrés
>>> >
>>> >
>>> > On Thu, Apr 17, 2014 at 9:48 AM, Rory Walsh  wrote:
>>> >>
>>> >> Does anyone else have any thoughts on this? I could of course parse
>>> >> the Csound text myself but this seems a bit extreme..
>>> >>
>>> >> On 16 April 2014 16:19, Rory Walsh  wrote:
>>> >> > If you are displaying and editing the table it can be useful to know
>>> >> > what GEN routine was used to create it. Otherwise you could end up
>>> >> > drawing straight lines in a table whose gen routine is used to create
>>> >> > exponential curves. If I could query the GEN number I could ensure
>>> >> > that my tables behave the same way as Csound's. So if one displays a
>>> >> > gen07 table I know that it's straight lines all the way. But I can't
>>> >> > tell it's gen anything from looking at the values.
>>> >> >
>>> >> > On 16 April 2014 15:00,   wrote:
>>> >> >> Not sure this is a meaningful concept.  A table contains values, and
>>> >> >> that is all
>>> >> >>
>>> >> >> Quoting Andres Cabrera :
>>> >> >>
>>> >> >>> I guess it could be added if it's not there, but there might be
>>> >> >>> additional
>>> >> >>> changes after creation using opcodes or the API.
>>> >> >>>
>>> >> >>> Cheers,
>>> >> >>> Andrés
>>> >> >>>
>>> >> >>>
>>> >> >>> On Wed, Apr 16, 2014 at 6:42 AM, Rory Walsh 
>>> >> >>> wrote:
>>> >> >>>
>>> >> >>>> Is there a mechanism to find out what gen routine was used to
>>> >> >>>> create
>>> >> >>>> a
>>> >> >>>> particular table. I took a look at the FUNC structure but couldn't
>>> >> >>>> see
>>> >> >>>> anything?
>>> >> >>>>
>>> >> >>>>
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> ------------------------------------------------------------------------------
>>> >> >>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> >> >>>> "Graph Databases" is the definitive new guide to graph databases
>>> >> >>>> and
>>> >> >>>> their
>>> >> >>>> applications. Written by three acclaimed leaders in the field,
>>> >> >>>> this first edition is now available. Download your free book
>>> >> >>>> today!
>>> >> >>>> http://p.sf.net/sfu/NeoTech
>>> >> >>>> _______________________________________________
>>> >> >>>> Csound-devel mailing list
>>> >> >>>> Csound-devel@lists.sourceforge.net
>>> >> >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >> >>>>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> ------------------------------------------------------------------------------
>>> >> >> Learn Graph Databases - Download FREE O'Reilly Book
>>> >> >> "Graph Databases" is the definitive new guide to graph databases and
>>> >> >> their
>>> >> >> applications. Written by three acclaimed leaders in the field,
>>> >> >> this first edition is now available. Download your free book today!
>>> >> >> http://p.sf.net/sfu/NeoTech
>>> >> >> _______________________________________________
>>> >> >> Csound-devel mailing list
>>> >> >> Csound-devel@lists.sourceforge.net
>>> >> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >>
>>> >>
>>> >>
>>> >> ------------------------------------------------------------------------------
>>> >> Learn Graph Databases - Download FREE O'Reilly Book
>>> >> "Graph Databases" is the definitive new guide to graph databases and
>>> >> their
>>> >> applications. Written by three acclaimed leaders in the field,
>>> >> this first edition is now available. Download your free book today!
>>> >> http://p.sf.net/sfu/NeoTech
>>> >> _______________________________________________
>>> >> Csound-devel mailing list
>>> >> Csound-devel@lists.sourceforge.net
>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >
>>> >
>>> >
>>> >
>>> > ------------------------------------------------------------------------------
>>> > Learn Graph Databases - Download FREE O'Reilly Book
>>> > "Graph Databases" is the definitive new guide to graph databases and
>>> > their
>>> > applications. Written by three acclaimed leaders in the field,
>>> > this first edition is now available. Download your free book today!
>>> > http://p.sf.net/sfu/NeoTech
>>> > _______________________________________________
>>> > Csound-devel mailing list
>>> > Csound-devel@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourc

Hi Steven. Thanks for chipping in here :) Let's take a most basic
example. An instrument creates the following tables on startup:

f1 0 1024 7 0 512 1 512 0

This clearly creates a breakpoint envelop with two points at either
end and one point half way through the table. Once users enter edit
mode Cabbage should display the table in the same fashion, i.e. using
three appropriately placed editable handles. Currently it does this
using a tracing routine that looks for changes in a vector's
trajectory and adds a handle if and when it sees a change. If however
I had access to the actual f-statement used to create the table it
would be so much easier to create an editable table based on the
actual f-statement rather than the resulting table data. My current
method leads to a lot of degradation in the table data because of my
rather crude tracing routines and I shudder to think how poor it will
work with non-linear curves. I hope I'm explaining myself correctly.
With access to the initial f-statement data I could recreate editable
versions of tables very quickly and with a high degree of accuracy.
What's more is I could then save and reopen them for editing as often
as I liked without messing up the table data.

This is of course the most basic of examples. There is a real
opportunity here for non-traditional table editing that doesn't really
exist anywhere else, simply because of the power of Csound's GEn
routines. For instance one could use handles not to edit the table
directly in terms of breakpoints, but to modify the amplitude of each
of the sinusoidal components that make up the table. I just can't see
how to do it effectively without having access to the that initial
score data. I already mentioned parsing the score for this data, but
it rules out a host of other gen/table opcodes. I'm all ears. Perhaps
there is another way of doing it without having to make the changes
suggested above. Can one access the list of events and search for
table data there?

On 17 April 2014 20:31, Steven Yi  wrote:
> I really dislike the idea of modifying Csound for this.  What exactly
> are you trying to do that couldn't be done by tracking things in your
> host?
>
> On Thu, Apr 17, 2014 at 2:23 PM, Rory Walsh  wrote:
>> That would be perfect for my needs. And yes, the last thing I want is
>> to introduce Cabbage only orchestra features. I'm still trying to get
>> my head around the inner workings of Csound, but am I right in
>> assuming that in any one of the gen functions found in fgens.c I would
>> need to access the EVTBLK member of the FGDATA structure to find out
>> the gen routine? I would then assign that, and the entire score
>> statement to two new members of FUNC so that it can be accessed via
>> csound->flist[]?
>>
>> On 17 April 2014 19:51, Andres Cabrera  wrote:
>>> I guess there could be a field in the table structure to hold the original
>>> data for creation. I would agree that having something Cabbage specific
>>> would be a bad idea. Fragmentation of the language is certainly not good.
>>>
>>> Cheers,
>>> Andrés
>>>
>>>
>>> On Thu, Apr 17, 2014 at 10:10 AM, Rory Walsh  wrote:
>>>>
>>>> That's more or less how I'm doing it at the moment but of course, in
>>>> my case, it forces users to create tables in the score(so much easier
>>>> to parse there). I would really like a generic solution to this but
>>>> it's looking more and more like I'll have to create some kind of
>>>> Cabbage table opcode. This would be a terrible solution IMO. I'm aware
>>>> that at any stage after creation a table could be modified so that the
>>>> gen line used to create it is redundant, but in the context of what
>>>> I'm trying to do this wouldn't be a problem. I just need to know what
>>>> was used to set up the table in the first place. I'm not talking so
>>>> much about traditional table editing whereby a user can drag and drop
>>>> a handle. I'm interested in abstracting the gen routines to offer a
>>>> new type of envelope editing.
>>>>
>>>> On 17 April 2014 18:52, Andres Cabrera  wrote:
>>>> > It seems messy to me as there is no guarantee that the data in the table
>>>> > actually corresponds to the gen line that would be contained in it. I
>>>> > think
>>>> > it is better to handle this within the front end.
>>>> >
>>>> > If you only allow this type of editing for tables created in a
>>>> > particular
>>>> > way, then you can store the information cleanly yourself without having
>>>> > to
>>>> > do any parsing of the file (which can get complicated if you support all
>>>> > the
>>>> > mechanisms ftgen, ftgentmp, f, socreline, etc.)
>>>> >
>>>> > Cheers,
>>>> > Andrés
>>>> >
>>>> >
>>>> > On Thu, Apr 17, 2014 at 9:48 AM, Rory Walsh  wrote:
>>>> >>
>>>> >> Does anyone else have any thoughts on this? I could of course parse
>>>> >> the Csound text myself but this seems a bit extreme..
>>>> >>
>>>> >> On 16 April 2014 16:19, Rory Walsh  wrote:
>>>> >> > If you are displaying and editing the table it can be useful to know
>>>> >> > what GEN routine was used to create it. Otherwise you could end up
>>>> >> > drawing straight lines in a table whose gen routine is used to create
>>>> >> > exponential curves. If I could query the GEN number I could ensure
>>>> >> > that my tables behave the same way as Csound's. So if one displays a
>>>> >> > gen07 table I know that it's straight lines all the way. But I can't
>>>> >> > tell it's gen anything from looking at the values.
>>>> >> >
>>>> >> > On 16 April 2014 15:00,   wrote:
>>>> >> >> Not sure this is a meaningful concept.  A table contains values, and
>>>> >> >> that is all
>>>> >> >>
>>>> >> >> Quoting Andres Cabrera :
>>>> >> >>
>>>> >> >>> I guess it could be added if it's not there, but there might be
>>>> >> >>> additional
>>>> >> >>> changes after creation using opcodes or the API.
>>>> >> >>>
>>>> >> >>> Cheers,
>>>> >> >>> Andrés
>>>> >> >>>
>>>> >> >>>
>>>> >> >>> On Wed, Apr 16, 2014 at 6:42 AM, Rory Walsh 
>>>> >> >>> wrote:
>>>> >> >>>
>>>> >> >>>> Is there a mechanism to find out what gen routine was used to
>>>> >> >>>> create
>>>> >> >>>> a
>>>> >> >>>> particular table. I took a look at the FUNC structure but couldn't
>>>> >> >>>> see
>>>> >> >>>> anything?
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> ------------------------------------------------------------------------------
>>>> >> >>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> >> >>>> "Graph Databases" is the definitive new guide to graph databases
>>>> >> >>>> and
>>>> >> >>>> their
>>>> >> >>>> applications. Written by three acclaimed leaders in the field,
>>>> >> >>>> this first edition is now available. Download your free book
>>>> >> >>>> today!
>>>> >> >>>> http://p.sf.net/sfu/NeoTech
>>>> >> >>>> _______________________________________________
>>>> >> >>>> Csound-devel mailing list
>>>> >> >>>> Csound-devel@lists.sourceforge.net
>>>> >> >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> >> >>>>
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >> ------------------------------------------------------------------------------
>>>> >> >> Learn Graph Databases - Download FREE O'Reilly Book
>>>> >> >> "Graph Databases" is the definitive new guide to graph databases and
>>>> >> >> their
>>>> >> >> applications. Written by three acclaimed leaders in the field,
>>>> >> >> this first edition is now available. Download your free book today!
>>>> >> >> http://p.sf.net/sfu/NeoTech
>>>> >> >> _______________________________________________
>>>> >> >> Csound-devel mailing list
>>>> >> >> Csound-devel@lists.sourceforge.net
>>>> >> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> >>
>>>> >>
>>>> >>
>>>> >> ------------------------------------------------------------------------------
>>>> >> Learn Graph Databases - Download FREE O'Reilly Book
>>>> >> "Graph Databases" is the definitive new guide to graph databases and
>>>> >> their
>>>> >> applications. Written by three acclaimed leaders in the field,
>>>> >> this first edition is now available. Download your free book today!
>>>> >> http://p.sf.net/sfu/NeoTech
>>>> >> _______________________________________________
>>>> >> Csound-devel mailing list
>>>> >> Csound-devel@lists.sourceforge.net
>>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > ------------------------------------------------------------------------------
>>>> > Learn Graph Databases - Download FREE O'Reilly Book
>>>> > "Graph Databases" is the definitive new guide to graph databases and
>>>> > their
>>>> > applications. Written by three acclaimed leaders in the field,
>>>> > this first edition is now available. Download your free book today!
>>>> > http://p.sf.net/sfu/NeoTech
>>>> > _______________________________________________
>>>> > Csound-devel mailing list
>>>> > Csound-devel@lists.sourceforge.net
>>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> >
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/NeoTech
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Andres,

I think you have email threads mixed up. I was replying to Rory's
comments about FGEN's holding external info, not the debugger. I like
the debugger just fine. :)

steven

On Thu, Apr 17, 2014 at 3:01 PM, Andres Cabrera  wrote:
> Hi Steven,
>
> It's the same question for C. Would you debug with printf or do you use the
> debugger to walk through your code? or to stop at any particular point to
> look at how things are in memory and then step line by line to see what your
> code is doing. Or to have Csound stop whenever a particular instrument is
> being triggered to look at the state of things to find why things are not
> working as expected. Most of these things could be done in a host, but the
> host would basically have to reimplement part of the csound engine so that
> it can pause senseevents and kperf while keeping the audio hardware
> "freewheeling".
>
> I have tried to be very careful to minimize the impact of the debugger in
> csound when you are not using it.
>
> You can build without debugger support (the default right now), in which
> case the only change is that kperf is now a function pointer within the
> CSOUND struct (which points to the old kperf without any changes).
>
> If you build with debugger support:
> 1) If you are not using the debugger, the only changes are that kperf is a
> function pointer, and this check in senseevents:
> #ifdef CSDEBUGGER
>     csdebug_data_t *data = (csdebug_data_t *) csound->csdebug_data;
>     if (data && data->status == CSDEBUG_STATUS_STOPPED) {
>         return 0; /* don't process events if we're in debug mode and stopped
> */
>     }
> #endif
>
> 2) if you are using the debugger, then instead of running the traditional
> kperf function, a kperf_debug function is called which checks whether
> breakpoints have been added/removed, and whether breakpoints have been
> reached or the user has requested a stop.
>
> What do you think?
>
> Cheers,
> Andrés
>
>
>
>
> On Thu, Apr 17, 2014 at 11:31 AM, Steven Yi  wrote:
>>
>> I really dislike the idea of modifying Csound for this.  What exactly
>> are you trying to do that couldn't be done by tracking things in your
>> host?
>>
>> On Thu, Apr 17, 2014 at 2:23 PM, Rory Walsh  wrote:
>> > That would be perfect for my needs. And yes, the last thing I want is
>> > to introduce Cabbage only orchestra features. I'm still trying to get
>> > my head around the inner workings of Csound, but am I right in
>> > assuming that in any one of the gen functions found in fgens.c I would
>> > need to access the EVTBLK member of the FGDATA structure to find out
>> > the gen routine? I would then assign that, and the entire score
>> > statement to two new members of FUNC so that it can be accessed via
>> > csound->flist[]?
>> >
>> > On 17 April 2014 19:51, Andres Cabrera  wrote:
>> >> I guess there could be a field in the table structure to hold the
>> >> original
>> >> data for creation. I would agree that having something Cabbage specific
>> >> would be a bad idea. Fragmentation of the language is certainly not
>> >> good.
>> >>
>> >> Cheers,
>> >> Andrés
>> >>
>> >>
>> >> On Thu, Apr 17, 2014 at 10:10 AM, Rory Walsh  wrote:
>> >>>
>> >>> That's more or less how I'm doing it at the moment but of course, in
>> >>> my case, it forces users to create tables in the score(so much easier
>> >>> to parse there). I would really like a generic solution to this but
>> >>> it's looking more and more like I'll have to create some kind of
>> >>> Cabbage table opcode. This would be a terrible solution IMO. I'm aware
>> >>> that at any stage after creation a table could be modified so that the
>> >>> gen line used to create it is redundant, but in the context of what
>> >>> I'm trying to do this wouldn't be a problem. I just need to know what
>> >>> was used to set up the table in the first place. I'm not talking so
>> >>> much about traditional table editing whereby a user can drag and drop
>> >>> a handle. I'm interested in abstracting the gen routines to offer a
>> >>> new type of envelope editing.
>> >>>
>> >>> On 17 April 2014 18:52, Andres Cabrera  wrote:
>> >>> > It seems messy to me as there is no guarantee that the data in the
>> >>> > table
>> >>> > actually corresponds to the gen line that would be contained in it.
>> >>> > I
>> >>> > think
>> >>> > it is better to handle this within the front end.
>> >>> >
>> >>> > If you only allow this type of editing for tables created in a
>> >>> > particular
>> >>> > way, then you can store the information cleanly yourself without
>> >>> > having
>> >>> > to
>> >>> > do any parsing of the file (which can get complicated if you support
>> >>> > all
>> >>> > the
>> >>> > mechanisms ftgen, ftgentmp, f, socreline, etc.)
>> >>> >
>> >>> > Cheers,
>> >>> > Andrés
>> >>> >
>> >>> >
>> >>> > On Thu, Apr 17, 2014 at 9:48 AM, Rory Walsh 
>> >>> > wrote:
>> >>> >>
>> >>> >> Does anyone else have any thoughts on this? I could of course parse
>> >>> >> the Csound text myself but this seems a bit extreme..
>> >>> >>
>> >>> >> On 16 April 2014 16:19, Rory Walsh  wrote:
>> >>> >> > If you are displaying and editing the table it can be useful to
>> >>> >> > know
>> >>> >> > what GEN routine was used to create it. Otherwise you could end
>> >>> >> > up
>> >>> >> > drawing straight lines in a table whose gen routine is used to
>> >>> >> > create
>> >>> >> > exponential curves. If I could query the GEN number I could
>> >>> >> > ensure
>> >>> >> > that my tables behave the same way as Csound's. So if one
>> >>> >> > displays a
>> >>> >> > gen07 table I know that it's straight lines all the way. But I
>> >>> >> > can't
>> >>> >> > tell it's gen anything from looking at the values.
>> >>> >> >
>> >>> >> > On 16 April 2014 15:00,   wrote:
>> >>> >> >> Not sure this is a meaningful concept.  A table contains values,
>> >>> >> >> and
>> >>> >> >> that is all
>> >>> >> >>
>> >>> >> >> Quoting Andres Cabrera :
>> >>> >> >>
>> >>> >> >>> I guess it could be added if it's not there, but there might be
>> >>> >> >>> additional
>> >>> >> >>> changes after creation using opcodes or the API.
>> >>> >> >>>
>> >>> >> >>> Cheers,
>> >>> >> >>> Andrés
>> >>> >> >>>
>> >>> >> >>>
>> >>> >> >>> On Wed, Apr 16, 2014 at 6:42 AM, Rory Walsh 
>> >>> >> >>> wrote:
>> >>> >> >>>
>> >>> >> >>>> Is there a mechanism to find out what gen routine was used to
>> >>> >> >>>> create
>> >>> >> >>>> a
>> >>> >> >>>> particular table. I took a look at the FUNC structure but
>> >>> >> >>>> couldn't
>> >>> >> >>>> see
>> >>> >> >>>> anything?
>> >>> >> >>>>
>> >>> >> >>>>
>> >>> >> >>>>
>> >>> >> >>>>
>> >>> >> >>>>
>> >>> >> >>>> ------------------------------------------------------------------------------
>> >>> >> >>>> Learn Graph Databases - Download FREE O'Reilly Book
>> >>> >> >>>> "Graph Databases" is the definitive new guide to graph
>> >>> >> >>>> databases
>> >>> >> >>>> and
>> >>> >> >>>> their
>> >>> >> >>>> applications. Written by three acclaimed leaders in the field,
>> >>> >> >>>> this first edition is now available. Download your free book
>> >>> >> >>>> today!
>> >>> >> >>>> http://p.sf.net/sfu/NeoTech
>> >>> >> >>>> _______________________________________________
>> >>> >> >>>> Csound-devel mailing list
>> >>> >> >>>> Csound-devel@lists.sourceforge.net
>> >>> >> >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >> >>>>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> ------------------------------------------------------------------------------
>> >>> >> >> Learn Graph Databases - Download FREE O'Reilly Book
>> >>> >> >> "Graph Databases" is the definitive new guide to graph databases
>> >>> >> >> and
>> >>> >> >> their
>> >>> >> >> applications. Written by three acclaimed leaders in the field,
>> >>> >> >> this first edition is now available. Download your free book
>> >>> >> >> today!
>> >>> >> >> http://p.sf.net/sfu/NeoTech
>> >>> >> >> _______________________________________________
>> >>> >> >> Csound-devel mailing list
>> >>> >> >> Csound-devel@lists.sourceforge.net
>> >>> >> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> ------------------------------------------------------------------------------
>> >>> >> Learn Graph Databases - Download FREE O'Reilly Book
>> >>> >> "Graph Databases" is the definitive new guide to graph databases
>> >>> >> and
>> >>> >> their
>> >>> >> applications. Written by three acclaimed leaders in the field,
>> >>> >> this first edition is now available. Download your free book today!
>> >>> >> http://p.sf.net/sfu/NeoTech
>> >>> >> _______________________________________________
>> >>> >> Csound-devel mailing list
>> >>> >> Csound-devel@lists.sourceforge.net
>> >>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > ------------------------------------------------------------------------------
>> >>> > Learn Graph Databases - Download FREE O'Reilly Book
>> >>> > "Graph Databases" is the definitive new guide to graph databases and
>> >>> > their
>> >>> > applications. Written by three acclaimed leaders in the field,
>> >>> > this first edition is now available. Download your free book today!
>> >>> > http://p.sf.net/sfu/NeoTech
>> >>> > _______________________________________________
>> >>> > Csound-devel mailing list
>> >>> > Csound-devel@lists.sourceforge.net
>> >>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> Learn Graph Databases - Download FREE O'Reilly Book
>> >>> "Graph Databases" is the definitive new guide to graph databases and
>> >>> their
>> >>> applications. Written by three acclaimed leaders in the field,
>> >>> this first edition is now available. Download your free book today!
>> >>> http://p.sf.net/sfu/NeoTech
>> >>> _______________________________________________
>> >>> Csound-devel mailing list
>> >>> Csound-devel@lists.sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Learn Graph Databases - Download FREE O'Reilly Book
>> >> "Graph Databases" is the definitive new guide to graph databases and
>> >> their
>> >> applications. Written by three acclaimed leaders in the field,
>> >> this first edition is now available. Download your free book today!
>> >> http://p.sf.net/sfu/NeoTech
>> >> _______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Learn Graph Databases - Download FREE O'Reilly Book
>> > "Graph Databases" is the definitive new guide to graph databases and
>> > their
>> > applications. Written by three acclaimed leaders in the field,
>> > this first edition is now available. Download your free book today!
>> > http://p.sf.net/sfu/NeoTech
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://

I think my point of view is that why not build a widget that
creates/modifies f-tables, rather than trying to figure out from an
ftable then build a widget?   Let's say you have a table widget.  It
could have fields like what gen routine to use, what ftable number to
use, etc.  At program start, during an initialization pass, have the
widgets call Csound and generate ftables. Your Csound code could
depend on the ftable num that you assigned to your widget. You could
alternatively do something like create an ftable, find the assigned
number, then send that over a channel. Your code then could look for
ftable numbers from a channel.



On Thu, Apr 17, 2014 at 3:08 PM, Rory Walsh  wrote:
> Hi Steven. Thanks for chipping in here :) Let's take a most basic
> example. An instrument creates the following tables on startup:
>
> f1 0 1024 7 0 512 1 512 0
>
> This clearly creates a breakpoint envelop with two points at either
> end and one point half way through the table. Once users enter edit
> mode Cabbage should display the table in the same fashion, i.e. using
> three appropriately placed editable handles. Currently it does this
> using a tracing routine that looks for changes in a vector's
> trajectory and adds a handle if and when it sees a change. If however
> I had access to the actual f-statement used to create the table it
> would be so much easier to create an editable table based on the
> actual f-statement rather than the resulting table data. My current
> method leads to a lot of degradation in the table data because of my
> rather crude tracing routines and I shudder to think how poor it will
> work with non-linear curves. I hope I'm explaining myself correctly.
> With access to the initial f-statement data I could recreate editable
> versions of tables very quickly and with a high degree of accuracy.
> What's more is I could then save and reopen them for editing as often
> as I liked without messing up the table data.
>
> This is of course the most basic of examples. There is a real
> opportunity here for non-traditional table editing that doesn't really
> exist anywhere else, simply because of the power of Csound's GEn
> routines. For instance one could use handles not to edit the table
> directly in terms of breakpoints, but to modify the amplitude of each
> of the sinusoidal components that make up the table. I just can't see
> how to do it effectively without having access to the that initial
> score data. I already mentioned parsing the score for this data, but
> it rules out a host of other gen/table opcodes. I'm all ears. Perhaps
> there is another way of doing it without having to make the changes
> suggested above. Can one access the list of events and search for
> table data there?
>
> On 17 April 2014 20:31, Steven Yi  wrote:
>> I really dislike the idea of modifying Csound for this.  What exactly
>> are you trying to do that couldn't be done by tracking things in your
>> host?
>>
>> On Thu, Apr 17, 2014 at 2:23 PM, Rory Walsh  wrote:
>>> That would be perfect for my needs. And yes, the last thing I want is
>>> to introduce Cabbage only orchestra features. I'm still trying to get
>>> my head around the inner workings of Csound, but am I right in
>>> assuming that in any one of the gen functions found in fgens.c I would
>>> need to access the EVTBLK member of the FGDATA structure to find out
>>> the gen routine? I would then assign that, and the entire score
>>> statement to two new members of FUNC so that it can be accessed via
>>> csound->flist[]?
>>>
>>> On 17 April 2014 19:51, Andres Cabrera  wrote:
>>>> I guess there could be a field in the table structure to hold the original
>>>> data for creation. I would agree that having something Cabbage specific
>>>> would be a bad idea. Fragmentation of the language is certainly not good.
>>>>
>>>> Cheers,
>>>> Andrés
>>>>
>>>>
>>>> On Thu, Apr 17, 2014 at 10:10 AM, Rory Walsh  wrote:
>>>>>
>>>>> That's more or less how I'm doing it at the moment but of course, in
>>>>> my case, it forces users to create tables in the score(so much easier
>>>>> to parse there). I would really like a generic solution to this but
>>>>> it's looking more and more like I'll have to create some kind of
>>>>> Cabbage table opcode. This would be a terrible solution IMO. I'm aware
>>>>> that at any stage after creation a table could be modified so that the
>>>>> gen line used to create it is redundant, but in the context of what
>>>>> I'm trying to do this wouldn't be a problem. I just need to know what
>>>>> was used to set up the table in the first place. I'm not talking so
>>>>> much about traditional table editing whereby a user can drag and drop
>>>>> a handle. I'm interested in abstracting the gen routines to offer a
>>>>> new type of envelope editing.
>>>>>
>>>>> On 17 April 2014 18:52, Andres Cabrera  wrote:
>>>>> > It seems messy to me as there is no guarantee that the data in the table
>>>>> > actually corresponds to the gen line that would be contained in it. I
>>>>> > think
>>>>> > it is better to handle this within the front end.
>>>>> >
>>>>> > If you only allow this type of editing for tables created in a
>>>>> > particular
>>>>> > way, then you can store the information cleanly yourself without having
>>>>> > to
>>>>> > do any parsing of the file (which can get complicated if you support all
>>>>> > the
>>>>> > mechanisms ftgen, ftgentmp, f, socreline, etc.)
>>>>> >
>>>>> > Cheers,
>>>>> > Andrés
>>>>> >
>>>>> >
>>>>> > On Thu, Apr 17, 2014 at 9:48 AM, Rory Walsh  wrote:
>>>>> >>
>>>>> >> Does anyone else have any thoughts on this? I could of course parse
>>>>> >> the Csound text myself but this seems a bit extreme..
>>>>> >>
>>>>> >> On 16 April 2014 16:19, Rory Walsh  wrote:
>>>>> >> > If you are displaying and editing the table it can be useful to know
>>>>> >> > what GEN routine was used to create it. Otherwise you could end up
>>>>> >> > drawing straight lines in a table whose gen routine is used to create
>>>>> >> > exponential curves. If I could query the GEN number I could ensure
>>>>> >> > that my tables behave the same way as Csound's. So if one displays a
>>>>> >> > gen07 table I know that it's straight lines all the way. But I can't
>>>>> >> > tell it's gen anything from looking at the values.
>>>>> >> >
>>>>> >> > On 16 April 2014 15:00,   wrote:
>>>>> >> >> Not sure this is a meaningful concept.  A table contains values, and
>>>>> >> >> that is all
>>>>> >> >>
>>>>> >> >> Quoting Andres Cabrera :
>>>>> >> >>
>>>>> >> >>> I guess it could be added if it's not there, but there might be
>>>>> >> >>> additional
>>>>> >> >>> changes after creation using opcodes or the API.
>>>>> >> >>>
>>>>> >> >>> Cheers,
>>>>> >> >>> Andrés
>>>>> >> >>>
>>>>> >> >>>
>>>>> >> >>> On Wed, Apr 16, 2014 at 6:42 AM, Rory Walsh 
>>>>> >> >>> wrote:
>>>>> >> >>>
>>>>> >> >>>> Is there a mechanism to find out what gen routine was used to
>>>>> >> >>>> create
>>>>> >> >>>> a
>>>>> >> >>>> particular table. I took a look at the FUNC structure but couldn't
>>>>> >> >>>> see
>>>>> >> >>>> anything?
>>>>> >> >>>>
>>>>> >> >>>>
>>>>> >> >>>>
>>>>> >> >>>>
>>>>> >> >>>> ------------------------------------------------------------------------------
>>>>> >> >>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>> >> >>>> "Graph Databases" is the definitive new guide to graph databases
>>>>> >> >>>> and
>>>>> >> >>>> their
>>>>> >> >>>> applications. Written by three acclaimed leaders in the field,
>>>>> >> >>>> this first edition is now available. Download your free book
>>>>> >> >>>> today!
>>>>> >> >>>> http://p.sf.net/sfu/NeoTech
>>>>> >> >>>> _______________________________________________
>>>>> >> >>>> Csound-devel mailing list
>>>>> >> >>>> Csound-devel@lists.sourceforge.net
>>>>> >> >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>> >> >>>>
>>>>> >> >>
>>>>> >> >>
>>>>> >> >>
>>>>> >> >>
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> ------------------------------------------------------------------------------
>>>>> >> >> Learn Graph Databases - Download FREE O'Reilly Book
>>>>> >> >> "Graph Databases" is the definitive new guide to graph databases and
>>>>> >> >> their
>>>>> >> >> applications. Written by three acclaimed leaders in the field,
>>>>> >> >> this first edition is now available. Download your free book today!
>>>>> >> >> http://p.sf.net/sfu/NeoTech
>>>>> >> >> _______________________________________________
>>>>> >> >> Csound-devel mailing list
>>>>> >> >> Csound-devel@lists.sourceforge.net
>>>>> >> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> ------------------------------------------------------------------------------
>>>>> >> Learn Graph Databases - Download FREE O'Reilly Book
>>>>> >> "Graph Databases" is the definitive new guide to graph databases and
>>>>> >> their
>>>>> >> applications. Written by three acclaimed leaders in the field,
>>>>> >> this first edition is now available. Download your free book today!
>>>>> >> http://p.sf.net/sfu/NeoTech
>>>>> >> _______________________________________________
>>>>> >> Csound-devel mailing list
>>>>> >> Csound-devel@lists.sourceforge.net
>>>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > ------------------------------------------------------------------------------
>>>>> > Learn Graph Databases - Download FREE O'Reilly Book
>>>>> > "Graph Databases" is the definitive new guide to graph databases and
>>>>> > their
>>>>> > applications. Written by three acclaimed leaders in the field,
>>>>> > this first edition is now available. Download your free book today!
>>>>> > http://p.sf.net/sfu/NeoTech
>>>>> > _______________________________________________
>>>>> > Csound-devel mailing list
>>>>> > Csound-devel@lists.sourceforge.net
>>>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>> >
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>>> applications. Written by three acclaimed leaders in the field,
>>>>> this first edition is now available. Download your free book today!
>>>>> http://p.sf.net/sfu/NeoTech
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/NeoTech
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https:

That's another way of doing it, but it would mean orchestra code found
in a Cabbage instruments could potentially be useless without Cabbage,
in which case wouldn't I be better off just writing a Cabbage table
opcode?(this would also be a lot simpler). Right now all Csound code
found in a Cabbage instrument will run fine in Blue, CsoundQT or any
future front-end, as everything in it is created using Csound and
Csound alone(channels excluded as they can easily be set up using any
modern front-end). Apart from this your suggestion would mean Cabbage
users need to know about Csound's GEN routines in order to modify or
create tables. One of the aims for Cabbage is that users don't need to
know anything about Csound in order to use the instruments. This
mythical table widget is of course just a concept right now, but would
adding two extra members to the FUNC data structure be such a bad
thing? Perhaps. You certainly know better than I. But is it not
possible to traverse a list of past EVENTS during performance? Is this
info not stored at all?




> I think my point of view is that why not build a widget that
> creates/modifies f-tables, rather than trying to figure out from an
> ftable then build a widget? Let's say you have a table widget.  It
> could have fields like what gen routine to use, what ftable number to
> use, etc.  At program start, during an initialization pass, have the
> widgets call Csound and generate ftables. Your Csound code could
> depend on the ftable num that you assigned to your widget. You could
> alternatively do something like create an ftable, find the assigned
> number, then send that over a channel. Your code then could look for
> ftable numbers from a channel.

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

In my local Csound build I've added an EVTBLK member to the FUNC data
structure that gets assigned in hfgens(). I then added a simple API
method to retrieve the evtblk for a given table number,
csoundTableGetEvtblk(CSOUND *csound, int table);
This seems pretty non-invasive to me and it gives me the data I need
in order to start exploring some radically new ways of editing tables.
The question is, is it something the devs might consider?



On 17 April 2014 22:42, Andres Cabrera  wrote:
> I don't think there currently is a list of these, but it would be cool if
> you could get a time stamped list of code that Csound compiled. That way you
> could recreate anything you created with live coding, making a fixed "score"
> from the live coding session (that can still be analyized, studied and
> changed).
>
> Cheers,
> Andrés
>
>
> On Thu, Apr 17, 2014 at 12:54 PM, Rory Walsh  wrote:
>>
>> That's another way of doing it, but it would mean orchestra code found
>> in a Cabbage instruments could potentially be useless without Cabbage,
>> in which case wouldn't I be better off just writing a Cabbage table
>> opcode?(this would also be a lot simpler). Right now all Csound code
>> found in a Cabbage instrument will run fine in Blue, CsoundQT or any
>> future front-end, as everything in it is created using Csound and
>> Csound alone(channels excluded as they can easily be set up using any
>> modern front-end). Apart from this your suggestion would mean Cabbage
>> users need to know about Csound's GEN routines in order to modify or
>> create tables. One of the aims for Cabbage is that users don't need to
>> know anything about Csound in order to use the instruments. This
>> mythical table widget is of course just a concept right now, but would
>> adding two extra members to the FUNC data structure be such a bad
>> thing? Perhaps. You certainly know better than I. But is it not
>> possible to traverse a list of past EVENTS during performance? Is this
>> info not stored at all?
>>
>>
>>
>>
>> > I think my point of view is that why not build a widget that
>> > creates/modifies f-tables, rather than trying to figure out from an
>> > ftable then build a widget? Let's say you have a table widget.  It
>> > could have fields like what gen routine to use, what ftable number to
>> > use, etc.  At program start, during an initialization pass, have the
>> > widgets call Csound and generate ftables. Your Csound code could
>> > depend on the ftable num that you assigned to your widget. You could
>> > alternatively do something like create an ftable, find the assigned
>> > number, then send that over a channel. Your code then could look for
>> > ftable numbers from a channel.
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

But if you created a table widget, you wouldn't have to expose the
Csound aspects of it to anyone.  The type of the table could be
handled internally, and you could show the user a nice popup menu. The
table number to write would only be a concern to the person writing
the Cabbage instrument/plugin, not the user of it.

At this point, I've become somewhat conservative when it comes to new
things with the API and internal structures.  A lot of has to do with
rewriting a great deal of things in CS6. There was a lot of "small
things" that were added over the years that solved someone's problem
and in turn made it difficult to figure out what was going on in the
codebase. These small things add up and impact clarity of code and
overall upkeep. I don't want anything like that to happen again, so I
hesitate on any new "small change".

As for the CSD being usable elsewhere, you could always create a
default ftable in csound code so that the code will function anywhere.

What I still don't understand is what exactly you're trying to build.
Is this a generic editor for any f-table found in a CSOUND structure?
Or something else?


On Thu, Apr 17, 2014 at 3:54 PM, Rory Walsh  wrote:
> That's another way of doing it, but it would mean orchestra code found
> in a Cabbage instruments could potentially be useless without Cabbage,
> in which case wouldn't I be better off just writing a Cabbage table
> opcode?(this would also be a lot simpler). Right now all Csound code
> found in a Cabbage instrument will run fine in Blue, CsoundQT or any
> future front-end, as everything in it is created using Csound and
> Csound alone(channels excluded as they can easily be set up using any
> modern front-end). Apart from this your suggestion would mean Cabbage
> users need to know about Csound's GEN routines in order to modify or
> create tables. One of the aims for Cabbage is that users don't need to
> know anything about Csound in order to use the instruments. This
> mythical table widget is of course just a concept right now, but would
> adding two extra members to the FUNC data structure be such a bad
> thing? Perhaps. You certainly know better than I. But is it not
> possible to traverse a list of past EVENTS during performance? Is this
> info not stored at all?
>
>
>
>
>> I think my point of view is that why not build a widget that
>> creates/modifies f-tables, rather than trying to figure out from an
>> ftable then build a widget? Let's say you have a table widget.  It
>> could have fields like what gen routine to use, what ftable number to
>> use, etc.  At program start, during an initialization pass, have the
>> widgets call Csound and generate ftables. Your Csound code could
>> depend on the ftable num that you assigned to your widget. You could
>> alternatively do something like create an ftable, find the assigned
>> number, then send that over a channel. Your code then could look for
>> ftable numbers from a channel.
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

As far as I understand, this is what happens with score:

There's two sets of events that are tracked. One is if a SCO is
compiled prior to running Csound. That gets read in, processed and
sorted, then written to disk as a temporary file. While Csound runs,
it has an open handle to the temp file and re-reads in a note at a
time. The event scheduler reads as much until a note that lies outside
the current ksmps period is found, then sets a wait time in number of
ksmps blocks to wait.  The next time the scheduler is called, it will
either keep waiting or start processing notes from the temp file
again.

The other set of events are realtime ones.  I think this originally
comes from the stdin line-events code, but it is reused for all
incoming score events. This systems differs from the SCO path. Score
events are saved as EVTBLK's and put into a list.  It gets processed
similarly to the SCO events, but I think once the EVTBLK is fired, it
gets removed from the list.

If you rewind the score, what happens?  The SCO path restarts but the
realtime one doesn't get "rewound" per-se.  Those events are gone.

In terms of engine designs, I don't think it makes sense personally to
try to track realtime events within Csound itself.  I'd rather see
Csound's core be as small as possible.  It makes more sense to me to
record realtime data and events at a higher level of software
architecture as it's much more flexible.

If we need to add some support internally, say, a callback that fires
whenever an event occurs, that might be feasible, but to try the track
the recording itself within Csound seems like it'll be tough to
satisfy everyone. Someone will say, well, what if I want to record
only certain events? or what if I want to split recording by
instrument? Or what if I want a single giant recording?  etc.  We'd
have to chase down trying to do everything internally, or rather, let
everything be possible externally and keep the internals simpler.

That said, what we could also consider is another csound library,
perhaps even one based on CsoundObj, that we distribute with Csound.
libcsound would be the simplest, cleanest part, and CsoundObj could
have higher-level features that could be reusable.

On Thu, Apr 17, 2014 at 4:42 PM, Andres Cabrera  wrote:
> I don't think there currently is a list of these, but it would be cool if
> you could get a time stamped list of code that Csound compiled. That way you
> could recreate anything you created with live coding, making a fixed "score"
> from the live coding session (that can still be analyized, studied and
> changed).
>
> Cheers,
> Andrés
>
>
> On Thu, Apr 17, 2014 at 12:54 PM, Rory Walsh  wrote:
>>
>> That's another way of doing it, but it would mean orchestra code found
>> in a Cabbage instruments could potentially be useless without Cabbage,
>> in which case wouldn't I be better off just writing a Cabbage table
>> opcode?(this would also be a lot simpler). Right now all Csound code
>> found in a Cabbage instrument will run fine in Blue, CsoundQT or any
>> future front-end, as everything in it is created using Csound and
>> Csound alone(channels excluded as they can easily be set up using any
>> modern front-end). Apart from this your suggestion would mean Cabbage
>> users need to know about Csound's GEN routines in order to modify or
>> create tables. One of the aims for Cabbage is that users don't need to
>> know anything about Csound in order to use the instruments. This
>> mythical table widget is of course just a concept right now, but would
>> adding two extra members to the FUNC data structure be such a bad
>> thing? Perhaps. You certainly know better than I. But is it not
>> possible to traverse a list of past EVENTS during performance? Is this
>> info not stored at all?
>>
>>
>>
>>
>> > I think my point of view is that why not build a widget that
>> > creates/modifies f-tables, rather than trying to figure out from an
>> > ftable then build a widget? Let's say you have a table widget.  It
>> > could have fields like what gen routine to use, what ftable number to
>> > use, etc.  At program start, during an initialization pass, have the
>> > widgets call Csound and generate ftables. Your Csound code could
>> > depend on the ftable num that you assigned to your widget. You could
>> > alternatively do something like create an ftable, find the assigned
>> > number, then send that over a channel. Your code then could look for
>> > ftable numbers from a channel.
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/l

I still don't understand what is this "radically new ways of editing
tables" you are talking about.  What you're proposing seems a clean
change for getting the information you've talked about, but without
the big picture as to what you're trying to do, it's hard to say if
this is the best option or if there aren't other possibilities. We'd
also have to audit and know what are the cases where this might not
work for the use case (do table redefinitions affect things? What if
users are using opcodes that transform ftables? etc.)

On Fri, Apr 18, 2014 at 6:13 AM, Rory Walsh  wrote:
> In my local Csound build I've added an EVTBLK member to the FUNC data
> structure that gets assigned in hfgens(). I then added a simple API
> method to retrieve the evtblk for a given table number,
> csoundTableGetEvtblk(CSOUND *csound, int table);
> This seems pretty non-invasive to me and it gives me the data I need
> in order to start exploring some radically new ways of editing tables.
> The question is, is it something the devs might consider?
>
>
>
> On 17 April 2014 22:42, Andres Cabrera  wrote:
>> I don't think there currently is a list of these, but it would be cool if
>> you could get a time stamped list of code that Csound compiled. That way you
>> could recreate anything you created with live coding, making a fixed "score"
>> from the live coding session (that can still be analyized, studied and
>> changed).
>>
>> Cheers,
>> Andrés
>>
>>
>> On Thu, Apr 17, 2014 at 12:54 PM, Rory Walsh  wrote:
>>>
>>> That's another way of doing it, but it would mean orchestra code found
>>> in a Cabbage instruments could potentially be useless without Cabbage,
>>> in which case wouldn't I be better off just writing a Cabbage table
>>> opcode?(this would also be a lot simpler). Right now all Csound code
>>> found in a Cabbage instrument will run fine in Blue, CsoundQT or any
>>> future front-end, as everything in it is created using Csound and
>>> Csound alone(channels excluded as they can easily be set up using any
>>> modern front-end). Apart from this your suggestion would mean Cabbage
>>> users need to know about Csound's GEN routines in order to modify or
>>> create tables. One of the aims for Cabbage is that users don't need to
>>> know anything about Csound in order to use the instruments. This
>>> mythical table widget is of course just a concept right now, but would
>>> adding two extra members to the FUNC data structure be such a bad
>>> thing? Perhaps. You certainly know better than I. But is it not
>>> possible to traverse a list of past EVENTS during performance? Is this
>>> info not stored at all?
>>>
>>>
>>>
>>>
>>> > I think my point of view is that why not build a widget that
>>> > creates/modifies f-tables, rather than trying to figure out from an
>>> > ftable then build a widget? Let's say you have a table widget.  It
>>> > could have fields like what gen routine to use, what ftable number to
>>> > use, etc.  At program start, during an initialization pass, have the
>>> > widgets call Csound and generate ftables. Your Csound code could
>>> > depend on the ftable num that you assigned to your widget. You could
>>> > alternatively do something like create an ftable, find the assigned
>>> > number, then send that over a channel. Your code then could look for
>>> > ftable numbers from a channel.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
h

Ok, let's take the most basic example:

f1 0 1024 7 0 128 1 128 .5 128 1 256 .1 128 .2 256 0

With access to the underlying evetblk Cabbage can now open this table
in edit mode as shown in the attached screenshot1.png, with a handle
for each breakpoint. Quick and very easy to implement. Or take the
case of this simple table:

f1 0 1024 10 1 .5 .25

If I know the amplitudes of each of the sinusoidal components I can
offer users a way to interact directly with the harmonics. In
screenshot2.png markers are added on the y-axis so users can quickly
alter the amplitude of any of the harmonics. Without access to the
underlying gen data I would have to do an FFT analysis of this table
in order to offer that kind of functionality. Iain has written some
really great GEN examples for Cabbage whereby users tweak knobs and
sliders to modify waveforms displayed in a table widget. We were just
wondering if we couldn't somehow edit the gen parameters directly in
the table. Could be nice.

If users modify table data using a tab opcode after the table was
created then clearly the initial evtblk will no longer be relevant.
It's only relevant when a GEN routine was used to create the table.

I hope this makes things a little clearer?

On 18 April 2014 17:30, Steven Yi  wrote:
> I still don't understand what is this "radically new ways of editing
> tables" you are talking about.  What you're proposing seems a clean
> change for getting the information you've talked about, but without
> the big picture as to what you're trying to do, it's hard to say if
> this is the best option or if there aren't other possibilities. We'd
> also have to audit and know what are the cases where this might not
> work for the use case (do table redefinitions affect things? What if
> users are using opcodes that transform ftables? etc.)
>
> On Fri, Apr 18, 2014 at 6:13 AM, Rory Walsh  wrote:
>> In my local Csound build I've added an EVTBLK member to the FUNC data
>> structure that gets assigned in hfgens(). I then added a simple API
>> method to retrieve the evtblk for a given table number,
>> csoundTableGetEvtblk(CSOUND *csound, int table);
>> This seems pretty non-invasive to me and it gives me the data I need
>> in order to start exploring some radically new ways of editing tables.
>> The question is, is it something the devs might consider?
>>
>>
>>
>> On 17 April 2014 22:42, Andres Cabrera  wrote:
>>> I don't think there currently is a list of these, but it would be cool if
>>> you could get a time stamped list of code that Csound compiled. That way you
>>> could recreate anything you created with live coding, making a fixed "score"
>>> from the live coding session (that can still be analyized, studied and
>>> changed).
>>>
>>> Cheers,
>>> Andrés
>>>
>>>
>>> On Thu, Apr 17, 2014 at 12:54 PM, Rory Walsh  wrote:
>>>>
>>>> That's another way of doing it, but it would mean orchestra code found
>>>> in a Cabbage instruments could potentially be useless without Cabbage,
>>>> in which case wouldn't I be better off just writing a Cabbage table
>>>> opcode?(this would also be a lot simpler). Right now all Csound code
>>>> found in a Cabbage instrument will run fine in Blue, CsoundQT or any
>>>> future front-end, as everything in it is created using Csound and
>>>> Csound alone(channels excluded as they can easily be set up using any
>>>> modern front-end). Apart from this your suggestion would mean Cabbage
>>>> users need to know about Csound's GEN routines in order to modify or
>>>> create tables. One of the aims for Cabbage is that users don't need to
>>>> know anything about Csound in order to use the instruments. This
>>>> mythical table widget is of course just a concept right now, but would
>>>> adding two extra members to the FUNC data structure be such a bad
>>>> thing? Perhaps. You certainly know better than I. But is it not
>>>> possible to traverse a list of past EVENTS during performance? Is this
>>>> info not stored at all?
>>>>
>>>>
>>>>
>>>>
>>>> > I think my point of view is that why not build a widget that
>>>> > creates/modifies f-tables, rather than trying to figure out from an
>>>> > ftable then build a widget? Let's say you have a table widget.  It
>>>> > could have fields like what gen routine to use, what ftable number to
>>>> > use, etc.  At program start, during an initialization pass, have the
>>>> > widgets call Csound and generate ftables. Your Csound code could
>>>> > depend on the ftable num that you assigned to your widget. You could
>>>> > alternatively do something like create an ftable, find the assigned
>>>> > number, then send that over a channel. Your code then could look for
>>>> > ftable numbers from a channel.
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/NeoTech
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Btw, are ALL function tables creating using hfgens()? Even plugin
function tables?

On 19 April 2014 10:46, Rory Walsh  wrote:
> Ok, let's take the most basic example:
>
> f1 0 1024 7 0 128 1 128 .5 128 1 256 .1 128 .2 256 0
>
> With access to the underlying evetblk Cabbage can now open this table
> in edit mode as shown in the attached screenshot1.png, with a handle
> for each breakpoint. Quick and very easy to implement. Or take the
> case of this simple table:
>
> f1 0 1024 10 1 .5 .25
>
> If I know the amplitudes of each of the sinusoidal components I can
> offer users a way to interact directly with the harmonics. In
> screenshot2.png markers are added on the y-axis so users can quickly
> alter the amplitude of any of the harmonics. Without access to the
> underlying gen data I would have to do an FFT analysis of this table
> in order to offer that kind of functionality. Iain has written some
> really great GEN examples for Cabbage whereby users tweak knobs and
> sliders to modify waveforms displayed in a table widget. We were just
> wondering if we couldn't somehow edit the gen parameters directly in
> the table. Could be nice.
>
> If users modify table data using a tab opcode after the table was
> created then clearly the initial evtblk will no longer be relevant.
> It's only relevant when a GEN routine was used to create the table.
>
> I hope this makes things a little clearer?
>
> On 18 April 2014 17:30, Steven Yi  wrote:
>> I still don't understand what is this "radically new ways of editing
>> tables" you are talking about.  What you're proposing seems a clean
>> change for getting the information you've talked about, but without
>> the big picture as to what you're trying to do, it's hard to say if
>> this is the best option or if there aren't other possibilities. We'd
>> also have to audit and know what are the cases where this might not
>> work for the use case (do table redefinitions affect things? What if
>> users are using opcodes that transform ftables? etc.)
>>
>> On Fri, Apr 18, 2014 at 6:13 AM, Rory Walsh  wrote:
>>> In my local Csound build I've added an EVTBLK member to the FUNC data
>>> structure that gets assigned in hfgens(). I then added a simple API
>>> method to retrieve the evtblk for a given table number,
>>> csoundTableGetEvtblk(CSOUND *csound, int table);
>>> This seems pretty non-invasive to me and it gives me the data I need
>>> in order to start exploring some radically new ways of editing tables.
>>> The question is, is it something the devs might consider?
>>>
>>>
>>>
>>> On 17 April 2014 22:42, Andres Cabrera  wrote:
>>>> I don't think there currently is a list of these, but it would be cool if
>>>> you could get a time stamped list of code that Csound compiled. That way you
>>>> could recreate anything you created with live coding, making a fixed "score"
>>>> from the live coding session (that can still be analyized, studied and
>>>> changed).
>>>>
>>>> Cheers,
>>>> Andrés
>>>>
>>>>
>>>> On Thu, Apr 17, 2014 at 12:54 PM, Rory Walsh  wrote:
>>>>>
>>>>> That's another way of doing it, but it would mean orchestra code found
>>>>> in a Cabbage instruments could potentially be useless without Cabbage,
>>>>> in which case wouldn't I be better off just writing a Cabbage table
>>>>> opcode?(this would also be a lot simpler). Right now all Csound code
>>>>> found in a Cabbage instrument will run fine in Blue, CsoundQT or any
>>>>> future front-end, as everything in it is created using Csound and
>>>>> Csound alone(channels excluded as they can easily be set up using any
>>>>> modern front-end). Apart from this your suggestion would mean Cabbage
>>>>> users need to know about Csound's GEN routines in order to modify or
>>>>> create tables. One of the aims for Cabbage is that users don't need to
>>>>> know anything about Csound in order to use the instruments. This
>>>>> mythical table widget is of course just a concept right now, but would
>>>>> adding two extra members to the FUNC data structure be such a bad
>>>>> thing? Perhaps. You certainly know better than I. But is it not
>>>>> possible to traverse a list of past EVENTS during performance? Is this
>>>>> info not stored at all?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> > I think my point of view is that why not build a widget that
>>>>> > creates/modifies f-tables, rather than trying to figure out from an
>>>>> > ftable then build a widget? Let's say you have a table widget.  It
>>>>> > could have fields like what gen routine to use, what ftable number to
>>>>> > use, etc.  At program start, during an initialization pass, have the
>>>>> > widgets call Csound and generate ftables. Your Csound code could
>>>>> > depend on the ftable num that you assigned to your widget. You could
>>>>> > alternatively do something like create an ftable, find the assigned
>>>>> > number, then send that over a channel. Your code then could look for
>>>>> > ftable numbers from a channel.
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>>> applications. Written by three acclaimed leaders in the field,
>>>>> this first edition is now available. Download your free book today!
>>>>> http://p.sf.net/sfu/NeoTech
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/NeoTech
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I've another question :) The EVTBLK structure is an unknown type when
used in csound.h. So in order to do something like this:

PUBLIC EVTBLK csoundTableGetEvtblk(CSOUND *csound, int table);

I had to use a forward declaration. But would it be cleaner to just
return a void pointer that can easily be re-cast to EVTBLK?

On 20 April 2014 12:16,   wrote:
> I believe so.
>
> ==John
>
> Quoting Rory Walsh :
>
>> Btw, are ALL function tables creating using hfgens()? Even plugin
>> function tables?
>>
>> On 19 April 2014 10:46, Rory Walsh  wrote:
>>> Ok, let's take the most basic example:
>>>
>>> f1 0 1024 7 0 128 1 128 .5 128 1 256 .1 128 .2 256 0
>>>
>>> With access to the underlying evetblk Cabbage can now open this table
>>> in edit mode as shown in the attached screenshot1.png, with a handle
>>> for each breakpoint. Quick and very easy to implement. Or take the
>>> case of this simple table:
>>>
>>> f1 0 1024 10 1 .5 .25
>>>
>>> If I know the amplitudes of each of the sinusoidal components I can
>>> offer users a way to interact directly with the harmonics. In
>>> screenshot2.png markers are added on the y-axis so users can quickly
>>> alter the amplitude of any of the harmonics. Without access to the
>>> underlying gen data I would have to do an FFT analysis of this table
>>> in order to offer that kind of functionality. Iain has written some
>>> really great GEN examples for Cabbage whereby users tweak knobs and
>>> sliders to modify waveforms displayed in a table widget. We were just
>>> wondering if we couldn't somehow edit the gen parameters directly in
>>> the table. Could be nice.
>>>
>>> If users modify table data using a tab opcode after the table was
>>> created then clearly the initial evtblk will no longer be relevant.
>>> It's only relevant when a GEN routine was used to create the table.
>>>
>>> I hope this makes things a little clearer?
>>>
>>> On 18 April 2014 17:30, Steven Yi  wrote:
>>>> I still don't understand what is this "radically new ways of editing
>>>> tables" you are talking about.  What you're proposing seems a clean
>>>> change for getting the information you've talked about, but without
>>>> the big picture as to what you're trying to do, it's hard to say if
>>>> this is the best option or if there aren't other possibilities. We'd
>>>> also have to audit and know what are the cases where this might not
>>>> work for the use case (do table redefinitions affect things? What if
>>>> users are using opcodes that transform ftables? etc.)
>>>>
>>>> On Fri, Apr 18, 2014 at 6:13 AM, Rory Walsh  wrote:
>>>>> In my local Csound build I've added an EVTBLK member to the FUNC data
>>>>> structure that gets assigned in hfgens(). I then added a simple API
>>>>> method to retrieve the evtblk for a given table number,
>>>>> csoundTableGetEvtblk(CSOUND *csound, int table);
>>>>> This seems pretty non-invasive to me and it gives me the data I need
>>>>> in order to start exploring some radically new ways of editing tables.
>>>>> The question is, is it something the devs might consider?
>>>>>
>>>>>
>>>>>
>>>>> On 17 April 2014 22:42, Andres Cabrera  wrote:
>>>>>> I don't think there currently is a list of these, but it would be cool if
>>>>>> you could get a time stamped list of code that Csound compiled.
>>>>>> That way you
>>>>>> could recreate anything you created with live coding, making a
>>>>>> fixed "score"
>>>>>> from the live coding session (that can still be analyized, studied and
>>>>>> changed).
>>>>>>
>>>>>> Cheers,
>>>>>> Andrés
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 17, 2014 at 12:54 PM, Rory Walsh  wrote:
>>>>>>>
>>>>>>> That's another way of doing it, but it would mean orchestra code found
>>>>>>> in a Cabbage instruments could potentially be useless without Cabbage,
>>>>>>> in which case wouldn't I be better off just writing a Cabbage table
>>>>>>> opcode?(this would also be a lot simpler). Right now all Csound code
>>>>>>> found in a Cabbage instrument will run fine in Blue, CsoundQT or any
>>>>>>> future front-end, as everything in it is created using Csound and
>>>>>>> Csound alone(channels excluded as they can easily be set up using any
>>>>>>> modern front-end). Apart from this your suggestion would mean Cabbage
>>>>>>> users need to know about Csound's GEN routines in order to modify or
>>>>>>> create tables. One of the aims for Cabbage is that users don't need to
>>>>>>> know anything about Csound in order to use the instruments. This
>>>>>>> mythical table widget is of course just a concept right now, but would
>>>>>>> adding two extra members to the FUNC data structure be such a bad
>>>>>>> thing? Perhaps. You certainly know better than I. But is it not
>>>>>>> possible to traverse a list of past EVENTS during performance? Is this
>>>>>>> info not stored at all?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> > I think my point of view is that why not build a widget that
>>>>>>> > creates/modifies f-tables, rather than trying to figure out from an
>>>>>>> > ftable then build a widget? Let's say you have a table widget.  It
>>>>>>> > could have fields like what gen routine to use, what ftable number to
>>>>>>> > use, etc.  At program start, during an initialization pass, have the
>>>>>>> > widgets call Csound and generate ftables. Your Csound code could
>>>>>>> > depend on the ftable num that you assigned to your widget. You could
>>>>>>> > alternatively do something like create an ftable, find the assigned
>>>>>>> > number, then send that over a channel. Your code then could look for
>>>>>>> > ftable numbers from a channel.
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>>>> "Graph Databases" is the definitive new guide to graph
>>>>>>> databases and their
>>>>>>> applications. Written by three acclaimed leaders in the field,
>>>>>>> this first edition is now available. Download your free book today!
>>>>>>> http://p.sf.net/sfu/NeoTech
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>>> "Graph Databases" is the definitive new guide to graph databases
>>>>>> and their
>>>>>> applications. Written by three acclaimed leaders in the field,
>>>>>> this first edition is now available. Download your free book today!
>>>>>> http://p.sf.net/sfu/NeoTech
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>>> applications. Written by three acclaimed leaders in the field,
>>>>> this first edition is now available. Download your free book today!
>>>>> http://p.sf.net/sfu/NeoTech
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/NeoTech
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It's a little clearer, but I still don't think it's necessary to go
this route.  I've said my piece though on it; if you you're committed
to going this way and don't mind that there are edge cases where this
won't work, then go ahead and submit a pull request.  Someone will
take a look and merge it.

Just FYI: We're looking at later this upcoming week to start the 6.03
release process (possibly Friday to start the release branch).  Best
to get any pull request in sooner than later so we have more time to
test the change.

On Sat, Apr 19, 2014 at 4:46 AM, Rory Walsh  wrote:
> Ok, let's take the most basic example:
>
> f1 0 1024 7 0 128 1 128 .5 128 1 256 .1 128 .2 256 0
>
> With access to the underlying evetblk Cabbage can now open this table
> in edit mode as shown in the attached screenshot1.png, with a handle
> for each breakpoint. Quick and very easy to implement. Or take the
> case of this simple table:
>
> f1 0 1024 10 1 .5 .25
>
> If I know the amplitudes of each of the sinusoidal components I can
> offer users a way to interact directly with the harmonics. In
> screenshot2.png markers are added on the y-axis so users can quickly
> alter the amplitude of any of the harmonics. Without access to the
> underlying gen data I would have to do an FFT analysis of this table
> in order to offer that kind of functionality. Iain has written some
> really great GEN examples for Cabbage whereby users tweak knobs and
> sliders to modify waveforms displayed in a table widget. We were just
> wondering if we couldn't somehow edit the gen parameters directly in
> the table. Could be nice.
>
> If users modify table data using a tab opcode after the table was
> created then clearly the initial evtblk will no longer be relevant.
> It's only relevant when a GEN routine was used to create the table.
>
> I hope this makes things a little clearer?
>
> On 18 April 2014 17:30, Steven Yi  wrote:
>> I still don't understand what is this "radically new ways of editing
>> tables" you are talking about.  What you're proposing seems a clean
>> change for getting the information you've talked about, but without
>> the big picture as to what you're trying to do, it's hard to say if
>> this is the best option or if there aren't other possibilities. We'd
>> also have to audit and know what are the cases where this might not
>> work for the use case (do table redefinitions affect things? What if
>> users are using opcodes that transform ftables? etc.)
>>
>> On Fri, Apr 18, 2014 at 6:13 AM, Rory Walsh  wrote:
>>> In my local Csound build I've added an EVTBLK member to the FUNC data
>>> structure that gets assigned in hfgens(). I then added a simple API
>>> method to retrieve the evtblk for a given table number,
>>> csoundTableGetEvtblk(CSOUND *csound, int table);
>>> This seems pretty non-invasive to me and it gives me the data I need
>>> in order to start exploring some radically new ways of editing tables.
>>> The question is, is it something the devs might consider?
>>>
>>>
>>>
>>> On 17 April 2014 22:42, Andres Cabrera  wrote:
>>>> I don't think there currently is a list of these, but it would be cool if
>>>> you could get a time stamped list of code that Csound compiled. That way you
>>>> could recreate anything you created with live coding, making a fixed "score"
>>>> from the live coding session (that can still be analyized, studied and
>>>> changed).
>>>>
>>>> Cheers,
>>>> Andrés
>>>>
>>>>
>>>> On Thu, Apr 17, 2014 at 12:54 PM, Rory Walsh  wrote:
>>>>>
>>>>> That's another way of doing it, but it would mean orchestra code found
>>>>> in a Cabbage instruments could potentially be useless without Cabbage,
>>>>> in which case wouldn't I be better off just writing a Cabbage table
>>>>> opcode?(this would also be a lot simpler). Right now all Csound code
>>>>> found in a Cabbage instrument will run fine in Blue, CsoundQT or any
>>>>> future front-end, as everything in it is created using Csound and
>>>>> Csound alone(channels excluded as they can easily be set up using any
>>>>> modern front-end). Apart from this your suggestion would mean Cabbage
>>>>> users need to know about Csound's GEN routines in order to modify or
>>>>> create tables. One of the aims for Cabbage is that users don't need to
>>>>> know anything about Csound in order to use the instruments. This
>>>>> mythical table widget is of course just a concept right now, but would
>>>>> adding two extra members to the FUNC data structure be such a bad
>>>>> thing? Perhaps. You certainly know better than I. But is it not
>>>>> possible to traverse a list of past EVENTS during performance? Is this
>>>>> info not stored at all?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> > I think my point of view is that why not build a widget that
>>>>> > creates/modifies f-tables, rather than trying to figure out from an
>>>>> > ftable then build a widget? Let's say you have a table widget.  It
>>>>> > could have fields like what gen routine to use, what ftable number to
>>>>> > use, etc.  At program start, during an initialization pass, have the
>>>>> > widgets call Csound and generate ftables. Your Csound code could
>>>>> > depend on the ftable num that you assigned to your widget. You could
>>>>> > alternatively do something like create an ftable, find the assigned
>>>>> > number, then send that over a channel. Your code then could look for
>>>>> > ftable numbers from a channel.
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>>> applications. Written by three acclaimed leaders in the field,
>>>>> this first edition is now available. Download your free book today!
>>>>> http://p.sf.net/sfu/NeoTech
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/NeoTech
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/l

hi rory -

this sounds very promising to me. i was wondering: if a user changes the 
table in the way you describe, will you then write back the new gen 
parameters to the orc or sco? or will you leave the original csd unchanged?

best -

	joachim


Am 19.04.2014 10:46, schrieb Rory Walsh:
> Ok, let's take the most basic example:
>
> f1 0 1024 7 0 128 1 128 .5 128 1 256 .1 128 .2 256 0
>
> With access to the underlying evetblk Cabbage can now open this table
> in edit mode as shown in the attached screenshot1.png, with a handle
> for each breakpoint. Quick and very easy to implement. Or take the
> case of this simple table:
>
> f1 0 1024 10 1 .5 .25
>
> If I know the amplitudes of each of the sinusoidal components I can
> offer users a way to interact directly with the harmonics. In
> screenshot2.png markers are added on the y-axis so users can quickly
> alter the amplitude of any of the harmonics. Without access to the
> underlying gen data I would have to do an FFT analysis of this table
> in order to offer that kind of functionality. Iain has written some
> really great GEN examples for Cabbage whereby users tweak knobs and
> sliders to modify waveforms displayed in a table widget. We were just
> wondering if we couldn't somehow edit the gen parameters directly in
> the table. Could be nice.
>
> If users modify table data using a tab opcode after the table was
> created then clearly the initial evtblk will no longer be relevant.
> It's only relevant when a GEN routine was used to create the table.
>
> I hope this makes things a little clearer?
>
> On 18 April 2014 17:30, Steven Yi  wrote:
>> I still don't understand what is this "radically new ways of editing
>> tables" you are talking about.  What you're proposing seems a clean
>> change for getting the information you've talked about, but without
>> the big picture as to what you're trying to do, it's hard to say if
>> this is the best option or if there aren't other possibilities. We'd
>> also have to audit and know what are the cases where this might not
>> work for the use case (do table redefinitions affect things? What if
>> users are using opcodes that transform ftables? etc.)
>>
>> On Fri, Apr 18, 2014 at 6:13 AM, Rory Walsh  wrote:
>>> In my local Csound build I've added an EVTBLK member to the FUNC data
>>> structure that gets assigned in hfgens(). I then added a simple API
>>> method to retrieve the evtblk for a given table number,
>>> csoundTableGetEvtblk(CSOUND *csound, int table);
>>> This seems pretty non-invasive to me and it gives me the data I need
>>> in order to start exploring some radically new ways of editing tables.
>>> The question is, is it something the devs might consider?
>>>
>>>
>>>
>>> On 17 April 2014 22:42, Andres Cabrera  wrote:
>>>> I don't think there currently is a list of these, but it would be cool if
>>>> you could get a time stamped list of code that Csound compiled. That way you
>>>> could recreate anything you created with live coding, making a fixed "score"
>>>> from the live coding session (that can still be analyized, studied and
>>>> changed).
>>>>
>>>> Cheers,
>>>> Andrés
>>>>
>>>>
>>>> On Thu, Apr 17, 2014 at 12:54 PM, Rory Walsh  wrote:
>>>>>
>>>>> That's another way of doing it, but it would mean orchestra code found
>>>>> in a Cabbage instruments could potentially be useless without Cabbage,
>>>>> in which case wouldn't I be better off just writing a Cabbage table
>>>>> opcode?(this would also be a lot simpler). Right now all Csound code
>>>>> found in a Cabbage instrument will run fine in Blue, CsoundQT or any
>>>>> future front-end, as everything in it is created using Csound and
>>>>> Csound alone(channels excluded as they can easily be set up using any
>>>>> modern front-end). Apart from this your suggestion would mean Cabbage
>>>>> users need to know about Csound's GEN routines in order to modify or
>>>>> create tables. One of the aims for Cabbage is that users don't need to
>>>>> know anything about Csound in order to use the instruments. This
>>>>> mythical table widget is of course just a concept right now, but would
>>>>> adding two extra members to the FUNC data structure be such a bad
>>>>> thing? Perhaps. You certainly know better than I. But is it not
>>>>> possible to traverse a list of past EVENTS during performance? Is this
>>>>> info not stored at all?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> I think my point of view is that why not build a widget that
>>>>>> creates/modifies f-tables, rather than trying to figure out from an
>>>>>> ftable then build a widget? Let's say you have a table widget.  It
>>>>>> could have fields like what gen routine to use, what ftable number to
>>>>>> use, etc.  At program start, during an initialization pass, have the
>>>>>> widgets call Csound and generate ftables. Your Csound code could
>>>>>> depend on the ftable num that you assigned to your widget. You could
>>>>>> alternatively do something like create an ftable, find the assigned
>>>>>> number, then send that over a channel. Your code then could look for
>>>>>> ftable numbers from a channel.
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>>> applications. Written by three acclaimed leaders in the field,
>>>>> this first edition is now available. Download your free book today!
>>>>> http://p.sf.net/sfu/NeoTech
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/NeoTech
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>>
>>
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/

There is no rush. I was just floated the idea now because I didn't
want to end up some weeks exploring something that could potentially
be rejected by the devs. Thanks for the feedback.

On 20 April 2014 16:44, Steven Yi  wrote:
> It's a little clearer, but I still don't think it's necessary to go
> this route.  I've said my piece though on it; if you you're committed
> to going this way and don't mind that there are edge cases where this
> won't work, then go ahead and submit a pull request.  Someone will
> take a look and merge it.
>
> Just FYI: We're looking at later this upcoming week to start the 6.03
> release process (possibly Friday to start the release branch).  Best
> to get any pull request in sooner than later so we have more time to
> test the change.
>
> On Sat, Apr 19, 2014 at 4:46 AM, Rory Walsh  wrote:
>> Ok, let's take the most basic example:
>>
>> f1 0 1024 7 0 128 1 128 .5 128 1 256 .1 128 .2 256 0
>>
>> With access to the underlying evetblk Cabbage can now open this table
>> in edit mode as shown in the attached screenshot1.png, with a handle
>> for each breakpoint. Quick and very easy to implement. Or take the
>> case of this simple table:
>>
>> f1 0 1024 10 1 .5 .25
>>
>> If I know the amplitudes of each of the sinusoidal components I can
>> offer users a way to interact directly with the harmonics. In
>> screenshot2.png markers are added on the y-axis so users can quickly
>> alter the amplitude of any of the harmonics. Without access to the
>> underlying gen data I would have to do an FFT analysis of this table
>> in order to offer that kind of functionality. Iain has written some
>> really great GEN examples for Cabbage whereby users tweak knobs and
>> sliders to modify waveforms displayed in a table widget. We were just
>> wondering if we couldn't somehow edit the gen parameters directly in
>> the table. Could be nice.
>>
>> If users modify table data using a tab opcode after the table was
>> created then clearly the initial evtblk will no longer be relevant.
>> It's only relevant when a GEN routine was used to create the table.
>>
>> I hope this makes things a little clearer?
>>
>> On 18 April 2014 17:30, Steven Yi  wrote:
>>> I still don't understand what is this "radically new ways of editing
>>> tables" you are talking about.  What you're proposing seems a clean
>>> change for getting the information you've talked about, but without
>>> the big picture as to what you're trying to do, it's hard to say if
>>> this is the best option or if there aren't other possibilities. We'd
>>> also have to audit and know what are the cases where this might not
>>> work for the use case (do table redefinitions affect things? What if
>>> users are using opcodes that transform ftables? etc.)
>>>
>>> On Fri, Apr 18, 2014 at 6:13 AM, Rory Walsh  wrote:
>>>> In my local Csound build I've added an EVTBLK member to the FUNC data
>>>> structure that gets assigned in hfgens(). I then added a simple API
>>>> method to retrieve the evtblk for a given table number,
>>>> csoundTableGetEvtblk(CSOUND *csound, int table);
>>>> This seems pretty non-invasive to me and it gives me the data I need
>>>> in order to start exploring some radically new ways of editing tables.
>>>> The question is, is it something the devs might consider?
>>>>
>>>>
>>>>
>>>> On 17 April 2014 22:42, Andres Cabrera  wrote:
>>>>> I don't think there currently is a list of these, but it would be cool if
>>>>> you could get a time stamped list of code that Csound compiled. That way you
>>>>> could recreate anything you created with live coding, making a fixed "score"
>>>>> from the live coding session (that can still be analyized, studied and
>>>>> changed).
>>>>>
>>>>> Cheers,
>>>>> Andrés
>>>>>
>>>>>
>>>>> On Thu, Apr 17, 2014 at 12:54 PM, Rory Walsh  wrote:
>>>>>>
>>>>>> That's another way of doing it, but it would mean orchestra code found
>>>>>> in a Cabbage instruments could potentially be useless without Cabbage,
>>>>>> in which case wouldn't I be better off just writing a Cabbage table
>>>>>> opcode?(this would also be a lot simpler). Right now all Csound code
>>>>>> found in a Cabbage instrument will run fine in Blue, CsoundQT or any
>>>>>> future front-end, as everything in it is created using Csound and
>>>>>> Csound alone(channels excluded as they can easily be set up using any
>>>>>> modern front-end). Apart from this your suggestion would mean Cabbage
>>>>>> users need to know about Csound's GEN routines in order to modify or
>>>>>> create tables. One of the aims for Cabbage is that users don't need to
>>>>>> know anything about Csound in order to use the instruments. This
>>>>>> mythical table widget is of course just a concept right now, but would
>>>>>> adding two extra members to the FUNC data structure be such a bad
>>>>>> thing? Perhaps. You certainly know better than I. But is it not
>>>>>> possible to traverse a list of past EVENTS during performance? Is this
>>>>>> info not stored at all?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> > I think my point of view is that why not build a widget that
>>>>>> > creates/modifies f-tables, rather than trying to figure out from an
>>>>>> > ftable then build a widget? Let's say you have a table widget.  It
>>>>>> > could have fields like what gen routine to use, what ftable number to
>>>>>> > use, etc.  At program start, during an initialization pass, have the
>>>>>> > widgets call Csound and generate ftables. Your Csound code could
>>>>>> > depend on the ftable num that you assigned to your widget. You could
>>>>>> > alternatively do something like create an ftable, find the assigned
>>>>>> > number, then send that over a channel. Your code then could look for
>>>>>> > ftable numbers from a channel.
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>>>> applications. Written by three acclaimed leaders in the field,
>>>>>> this first edition is now available. Download your free book today!
>>>>>> http://p.sf.net/sfu/NeoTech
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>>> applications. Written by three acclaimed leaders in the field,
>>>>> this first edition is now available. Download your free book today!
>>>>> http://p.sf.net/sfu/NeoTech
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/NeoTech
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Joachim. That's right, the table widget can either overwrite the
previous statement, or enter a new f-statement into the score, it's up
to the end-user, and also depends on how the table was created.

On 20 April 2014 17:25, joachim heintz  wrote:
> hi rory -
>
> this sounds very promising to me. i was wondering: if a user changes the
> table in the way you describe, will you then write back the new gen
> parameters to the orc or sco? or will you leave the original csd unchanged?
>
> best -
>
>         joachim
>
>
> Am 19.04.2014 10:46, schrieb Rory Walsh:
>> Ok, let's take the most basic example:
>>
>> f1 0 1024 7 0 128 1 128 .5 128 1 256 .1 128 .2 256 0
>>
>> With access to the underlying evetblk Cabbage can now open this table
>> in edit mode as shown in the attached screenshot1.png, with a handle
>> for each breakpoint. Quick and very easy to implement. Or take the
>> case of this simple table:
>>
>> f1 0 1024 10 1 .5 .25
>>
>> If I know the amplitudes of each of the sinusoidal components I can
>> offer users a way to interact directly with the harmonics. In
>> screenshot2.png markers are added on the y-axis so users can quickly
>> alter the amplitude of any of the harmonics. Without access to the
>> underlying gen data I would have to do an FFT analysis of this table
>> in order to offer that kind of functionality. Iain has written some
>> really great GEN examples for Cabbage whereby users tweak knobs and
>> sliders to modify waveforms displayed in a table widget. We were just
>> wondering if we couldn't somehow edit the gen parameters directly in
>> the table. Could be nice.
>>
>> If users modify table data using a tab opcode after the table was
>> created then clearly the initial evtblk will no longer be relevant.
>> It's only relevant when a GEN routine was used to create the table.
>>
>> I hope this makes things a little clearer?
>>
>> On 18 April 2014 17:30, Steven Yi  wrote:
>>> I still don't understand what is this "radically new ways of editing
>>> tables" you are talking about.  What you're proposing seems a clean
>>> change for getting the information you've talked about, but without
>>> the big picture as to what you're trying to do, it's hard to say if
>>> this is the best option or if there aren't other possibilities. We'd
>>> also have to audit and know what are the cases where this might not
>>> work for the use case (do table redefinitions affect things? What if
>>> users are using opcodes that transform ftables? etc.)
>>>
>>> On Fri, Apr 18, 2014 at 6:13 AM, Rory Walsh  wrote:
>>>> In my local Csound build I've added an EVTBLK member to the FUNC data
>>>> structure that gets assigned in hfgens(). I then added a simple API
>>>> method to retrieve the evtblk for a given table number,
>>>> csoundTableGetEvtblk(CSOUND *csound, int table);
>>>> This seems pretty non-invasive to me and it gives me the data I need
>>>> in order to start exploring some radically new ways of editing tables.
>>>> The question is, is it something the devs might consider?
>>>>
>>>>
>>>>
>>>> On 17 April 2014 22:42, Andres Cabrera  wrote:
>>>>> I don't think there currently is a list of these, but it would be cool if
>>>>> you could get a time stamped list of code that Csound compiled. That way you
>>>>> could recreate anything you created with live coding, making a fixed "score"
>>>>> from the live coding session (that can still be analyized, studied and
>>>>> changed).
>>>>>
>>>>> Cheers,
>>>>> Andrés
>>>>>
>>>>>
>>>>> On Thu, Apr 17, 2014 at 12:54 PM, Rory Walsh  wrote:
>>>>>>
>>>>>> That's another way of doing it, but it would mean orchestra code found
>>>>>> in a Cabbage instruments could potentially be useless without Cabbage,
>>>>>> in which case wouldn't I be better off just writing a Cabbage table
>>>>>> opcode?(this would also be a lot simpler). Right now all Csound code
>>>>>> found in a Cabbage instrument will run fine in Blue, CsoundQT or any
>>>>>> future front-end, as everything in it is created using Csound and
>>>>>> Csound alone(channels excluded as they can easily be set up using any
>>>>>> modern front-end). Apart from this your suggestion would mean Cabbage
>>>>>> users need to know about Csound's GEN routines in order to modify or
>>>>>> create tables. One of the aims for Cabbage is that users don't need to
>>>>>> know anything about Csound in order to use the instruments. This
>>>>>> mythical table widget is of course just a concept right now, but would
>>>>>> adding two extra members to the FUNC data structure be such a bad
>>>>>> thing? Perhaps. You certainly know better than I. But is it not
>>>>>> possible to traverse a list of past EVENTS during performance? Is this
>>>>>> info not stored at all?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I think my point of view is that why not build a widget that
>>>>>>> creates/modifies f-tables, rather than trying to figure out from an
>>>>>>> ftable then build a widget? Let's say you have a table widget.  It
>>>>>>> could have fields like what gen routine to use, what ftable number to
>>>>>>> use, etc.  At program start, during an initialization pass, have the
>>>>>>> widgets call Csound and generate ftables. Your Csound code could
>>>>>>> depend on the ftable num that you assigned to your widget. You could
>>>>>>> alternatively do something like create an ftable, find the assigned
>>>>>>> number, then send that over a channel. Your code then could look for
>>>>>>> ftable numbers from a channel.
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>>>> applications. Written by three acclaimed leaders in the field,
>>>>>> this first edition is now available. Download your free book today!
>>>>>> http://p.sf.net/sfu/NeoTech
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>>> applications. Written by three acclaimed leaders in the field,
>>>>> this first edition is now available. Download your free book today!
>>>>> http://p.sf.net/sfu/NeoTech
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/NeoTech
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>>
>>>
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks John. Duly noted.

On 20 April 2014 15:02,   wrote:
> Surely you are not going to return a structure from a function?
> Make it *void and cast it
>
> Quoting Rory Walsh :
>
>> I've another question :) The EVTBLK structure is an unknown type when
>> used in csound.h. So in order to do something like this:
>>
>> PUBLIC EVTBLK csoundTableGetEvtblk(CSOUND *csound, int table);
>>
>> I had to use a forward declaration. But would it be cleaner to just
>> return a void pointer that can easily be re-cast to EVTBLK?
>>
>> On 20 April 2014 12:16,   wrote:
>>> I believe so.
>>>
>>> ==John
>>>
>>> Quoting Rory Walsh :
>>>
>>>> Btw, are ALL function tables creating using hfgens()? Even plugin
>>>> function tables?
>>>>
>>>> On 19 April 2014 10:46, Rory Walsh  wrote:
>>>>> Ok, let's take the most basic example:
>>>>>
>>>>> f1 0 1024 7 0 128 1 128 .5 128 1 256 .1 128 .2 256 0
>>>>>
>>>>> With access to the underlying evetblk Cabbage can now open this table
>>>>> in edit mode as shown in the attached screenshot1.png, with a handle
>>>>> for each breakpoint. Quick and very easy to implement. Or take the
>>>>> case of this simple table:
>>>>>
>>>>> f1 0 1024 10 1 .5 .25
>>>>>
>>>>> If I know the amplitudes of each of the sinusoidal components I can
>>>>> offer users a way to interact directly with the harmonics. In
>>>>> screenshot2.png markers are added on the y-axis so users can quickly
>>>>> alter the amplitude of any of the harmonics. Without access to the
>>>>> underlying gen data I would have to do an FFT analysis of this table
>>>>> in order to offer that kind of functionality. Iain has written some
>>>>> really great GEN examples for Cabbage whereby users tweak knobs and
>>>>> sliders to modify waveforms displayed in a table widget. We were just
>>>>> wondering if we couldn't somehow edit the gen parameters directly in
>>>>> the table. Could be nice.
>>>>>
>>>>> If users modify table data using a tab opcode after the table was
>>>>> created then clearly the initial evtblk will no longer be relevant.
>>>>> It's only relevant when a GEN routine was used to create the table.
>>>>>
>>>>> I hope this makes things a little clearer?
>>>>>
>>>>> On 18 April 2014 17:30, Steven Yi  wrote:
>>>>>> I still don't understand what is this "radically new ways of editing
>>>>>> tables" you are talking about.  What you're proposing seems a clean
>>>>>> change for getting the information you've talked about, but without
>>>>>> the big picture as to what you're trying to do, it's hard to say if
>>>>>> this is the best option or if there aren't other possibilities. We'd
>>>>>> also have to audit and know what are the cases where this might not
>>>>>> work for the use case (do table redefinitions affect things? What if
>>>>>> users are using opcodes that transform ftables? etc.)
>>>>>>
>>>>>> On Fri, Apr 18, 2014 at 6:13 AM, Rory Walsh  wrote:
>>>>>>> In my local Csound build I've added an EVTBLK member to the FUNC data
>>>>>>> structure that gets assigned in hfgens(). I then added a simple API
>>>>>>> method to retrieve the evtblk for a given table number,
>>>>>>> csoundTableGetEvtblk(CSOUND *csound, int table);
>>>>>>> This seems pretty non-invasive to me and it gives me the data I need
>>>>>>> in order to start exploring some radically new ways of editing tables.
>>>>>>> The question is, is it something the devs might consider?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 17 April 2014 22:42, Andres Cabrera  wrote:
>>>>>>>> I don't think there currently is a list of these, but it would
>>>>>>>> be cool if
>>>>>>>> you could get a time stamped list of code that Csound compiled.
>>>>>>>> That way you
>>>>>>>> could recreate anything you created with live coding, making a
>>>>>>>> fixed "score"
>>>>>>>> from the live coding session (that can still be analyized, studied and
>>>>>>>> changed).
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Andrés
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Apr 17, 2014 at 12:54 PM, Rory Walsh  wrote:
>>>>>>>>>
>>>>>>>>> That's another way of doing it, but it would mean orchestra code found
>>>>>>>>> in a Cabbage instruments could potentially be useless without Cabbage,
>>>>>>>>> in which case wouldn't I be better off just writing a Cabbage table
>>>>>>>>> opcode?(this would also be a lot simpler). Right now all Csound code
>>>>>>>>> found in a Cabbage instrument will run fine in Blue, CsoundQT or any
>>>>>>>>> future front-end, as everything in it is created using Csound and
>>>>>>>>> Csound alone(channels excluded as they can easily be set up using any
>>>>>>>>> modern front-end). Apart from this your suggestion would mean Cabbage
>>>>>>>>> users need to know about Csound's GEN routines in order to modify or
>>>>>>>>> create tables. One of the aims for Cabbage is that users don't need to
>>>>>>>>> know anything about Csound in order to use the instruments. This
>>>>>>>>> mythical table widget is of course just a concept right now, but would
>>>>>>>>> adding two extra members to the FUNC data structure be such a bad
>>>>>>>>> thing? Perhaps. You certainly know better than I. But is it not
>>>>>>>>> possible to traverse a list of past EVENTS during performance? Is this
>>>>>>>>> info not stored at all?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> > I think my point of view is that why not build a widget that
>>>>>>>>> > creates/modifies f-tables, rather than trying to figure out from an
>>>>>>>>> > ftable then build a widget? Let's say you have a table widget.  It
>>>>>>>>> > could have fields like what gen routine to use, what ftable
>>>>>>>>> number to
>>>>>>>>> > use, etc.  At program start, during an initialization pass, have the
>>>>>>>>> > widgets call Csound and generate ftables. Your Csound code could
>>>>>>>>> > depend on the ftable num that you assigned to your widget. You could
>>>>>>>>> > alternatively do something like create an ftable, find the assigned
>>>>>>>>> > number, then send that over a channel. Your code then could look for
>>>>>>>>> > ftable numbers from a channel.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>>>>>> "Graph Databases" is the definitive new guide to graph
>>>>>>>>> databases and their
>>>>>>>>> applications. Written by three acclaimed leaders in the field,
>>>>>>>>> this first edition is now available. Download your free book today!
>>>>>>>>> http://p.sf.net/sfu/NeoTech
>>>>>>>>> _______________________________________________
>>>>>>>>> Csound-devel mailing list
>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>>>>> "Graph Databases" is the definitive new guide to graph databases
>>>>>>>> and their
>>>>>>>> applications. Written by three acclaimed leaders in the field,
>>>>>>>> this first edition is now available. Download your free book today!
>>>>>>>> http://p.sf.net/sfu/NeoTech
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>>>> "Graph Databases" is the definitive new guide to graph
>>>>>>> databases and their
>>>>>>> applications. Written by three acclaimed leaders in the field,
>>>>>>> this first edition is now available. Download your free book today!
>>>>>>> http://p.sf.net/sfu/NeoTech
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>>> "Graph Databases" is the definitive new guide to graph databases
>>>>>> and their
>>>>>> applications. Written by three acclaimed leaders in the field,
>>>>>> this first edition is now available. Download your free book today!
>>>>>> http://p.sf.net/sfu/NeoTech
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases and their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/NeoTech
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net