Csound › Csound - Dev

ftfree

Classic

List

Threaded

24 messages Options

Steven Yi

ftfree

Hi All,

I'm working on ftree now and am putting it in fgens.c and adding a
struct to ftgen.h, and plan to add it to entry1.c. or entry2.c,
wherever ftgen is at. The reason I'm doing this within csound and not
as a plugin is that I haven't found any API functions which can do
this. I'm using the code from hfgens:

if (ff->fno > csound->maxfnum ||
(ftp = csound->flist[ff->fno]) == NULL) {
fterror(csound, ff, Str("ftable does not exist"));
return -1;
}
csound->flist[ff->fno] = NULL;
mfree(csound, (void*) ftp);

(with the ff->fno coming from *p instead) to free the table. Does
this all sound alright or is there an API way to do this? (And if not,
should there be?)

Thanks,
steven

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. <a href="http://ads.osdn.com/?ad_idt77&alloc_id492&op=click">http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Istvan Varga

Re: ftfree

For freeing a table with a known number, you can just use csound->hfgens()
with a negative table number which will request deleting the table, and
this should work from plugins. Alternatively, it may make sense to write
a version of the ftgen opcode that automatically deletes the table at
note deinit. It should be possible to implement that opcode as a plugin
(actually, ftgen may be moved out of fgens.c as well).

Steven Yi wrote:

> I'm working on ftree now and am putting it in fgens.c and adding a
> struct to ftgen.h, and plan to add it to entry1.c. or entry2.c,
> wherever ftgen is at. The reason I'm doing this within csound and not
> as a plugin is that I haven't found any API functions which can do
> this. I'm using the code from hfgens:
>
> if (ff->fno > csound->maxfnum ||
> (ftp = csound->flist[ff->fno]) == NULL) {
> fterror(csound, ff, Str("ftable does not exist"));
> return -1;
> }
> csound->flist[ff->fno] = NULL;
> mfree(csound, (void*) ftp);
>
> (with the ff->fno coming from *p instead) to free the table. Does
> this all sound alright or is there an API way to do this? (And if not,
> should there be?)

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Steven Yi

Re: ftfree

Hi Istvan,

Thanks for the information. I didn't see that hfgens was already in
the ENVIRON struct. I committed a version of the ftfree opcode an
hour or so ago that was in fgens.c and entry1.c. I'll work on pushing
it and ftgens and whatever opcodes that use structs in ftgen.h out to
an opcode plugin.

I ended up making ftfree take both the number of the table to free as
well as freeTime parameter that if equal to 0 to free at opcode init,
and if not zero to free at deinit time. Originally, I thought the
instrument I am translating had a temp array that was being generated
and free()'d in the code and then later realized it wasn't being used.
Maybe it's better to simplify and just delete at deinit anyways?
(Maybe I'll take that option out then.)

Do you think it's better to have an ftgentemp opcode where the table
is always deleted at deinit, or better to explicitly call ftfree? Is
there a use case where say, one instrument will generate a wavetable
and other instruments will use it for a while, then that instrument is
called again to generate a new ftable and free the old one? Hmm...
maybe not, as you could always just overwrite a table assigned to a
global var.

Okay, sounds like an ftgentemp would be a good solution to all of
this. I'll remove the ftfree opcode I put in and redo it all as an
opcode plugin.

Thanks!
steven

On 8/3/05, Istvan Varga <[hidden email]> wrote:

> For freeing a table with a known number, you can just use csound->hfgens()
> with a negative table number which will request deleting the table, and
> this should work from plugins. Alternatively, it may make sense to write
> a version of the ftgen opcode that automatically deletes the table at
> note deinit. It should be possible to implement that opcode as a plugin
> (actually, ftgen may be moved out of fgens.c as well).
>
> Steven Yi wrote:
>
> > I'm working on ftree now and am putting it in fgens.c and adding a
> > struct to ftgen.h, and plan to add it to entry1.c. or entry2.c,
> > wherever ftgen is at. The reason I'm doing this within csound and not
> > as a plugin is that I haven't found any API functions which can do
> > this. I'm using the code from hfgens:
> >
> > if (ff->fno > csound->maxfnum ||
> > (ftp = csound->flist[ff->fno]) == NULL) {
> > fterror(csound, ff, Str("ftable does not exist"));
> > return -1;
> > }
> > csound->flist[ff->fno] = NULL;
> > mfree(csound, (void*) ftp);
> >
> > (with the ff->fno coming from *p instead) to free the table. Does
> > this all sound alright or is there an API way to do this? (And if not,
> > should there be?)
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Csound-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. <a href="http://ads.osdn.com/?ad_idt77&alloc_id492&op=click">http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Steven Yi

Re: ftfree

Hi All,

I'm in the process of moving ftgen, ftload, ftload_k, ftsave, and
ftsave_k into an opcode plugin, but there is no mcalloc in ENVIRON.
What is the process of adding this in?

Thanks,
steven

On 8/3/05, Steven Yi <[hidden email]> wrote:

> Hi Istvan,
>
> Thanks for the information. I didn't see that hfgens was already in
> the ENVIRON struct. I committed a version of the ftfree opcode an
> hour or so ago that was in fgens.c and entry1.c. I'll work on pushing
> it and ftgens and whatever opcodes that use structs in ftgen.h out to
> an opcode plugin.
>
> I ended up making ftfree take both the number of the table to free as
> well as freeTime parameter that if equal to 0 to free at opcode init,
> and if not zero to free at deinit time. Originally, I thought the
> instrument I am translating had a temp array that was being generated
> and free()'d in the code and then later realized it wasn't being used.
> Maybe it's better to simplify and just delete at deinit anyways?
> (Maybe I'll take that option out then.)
>
> Do you think it's better to have an ftgentemp opcode where the table
> is always deleted at deinit, or better to explicitly call ftfree? Is
> there a use case where say, one instrument will generate a wavetable
> and other instruments will use it for a while, then that instrument is
> called again to generate a new ftable and free the old one? Hmm...
> maybe not, as you could always just overwrite a table assigned to a
> global var.
>
> Okay, sounds like an ftgentemp would be a good solution to all of
> this. I'll remove the ftfree opcode I put in and redo it all as an
> opcode plugin.
>
> Thanks!
> steven
>
>
> On 8/3/05, Istvan Varga <[hidden email]> wrote:
> > For freeing a table with a known number, you can just use csound->hfgens()
> > with a negative table number which will request deleting the table, and
> > this should work from plugins. Alternatively, it may make sense to write
> > a version of the ftgen opcode that automatically deletes the table at
> > note deinit. It should be possible to implement that opcode as a plugin
> > (actually, ftgen may be moved out of fgens.c as well).
> >
> > Steven Yi wrote:
> >
> > > I'm working on ftree now and am putting it in fgens.c and adding a
> > > struct to ftgen.h, and plan to add it to entry1.c. or entry2.c,
> > > wherever ftgen is at. The reason I'm doing this within csound and not
> > > as a plugin is that I haven't found any API functions which can do
> > > this. I'm using the code from hfgens:
> > >
> > > if (ff->fno > csound->maxfnum ||
> > > (ftp = csound->flist[ff->fno]) == NULL) {
> > > fterror(csound, ff, Str("ftable does not exist"));
> > > return -1;
> > > }
> > > csound->flist[ff->fno] = NULL;
> > > mfree(csound, (void*) ftp);
> > >
> > > (with the ff->fno coming from *p instead) to free the table. Does
> > > this all sound alright or is there an API way to do this? (And if not,
> > > should there be?)
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > Csound-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
>

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. <a href="http://ads.osdn.com/?ad_idt77&alloc_id492&op=click">http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Steven Yi

Re: ftfree

Hmm... after more work, I think I want to just forget pushing this all
into its own opcode library and will just remove ftfree and put in
ftgentemp. I got a point of code where it was trying to access
csound->ff and that only gets compiled in when it is building csound
as a library.

Anyways, so will remove what I just did and start again! =)

steven

On 8/3/05, Steven Yi <[hidden email]> wrote:

> Hi All,
>
> I'm in the process of moving ftgen, ftload, ftload_k, ftsave, and
> ftsave_k into an opcode plugin, but there is no mcalloc in ENVIRON.
> What is the process of adding this in?
>
> Thanks,
> steven
>
>
>
> On 8/3/05, Steven Yi <[hidden email]> wrote:
> > Hi Istvan,
> >
> > Thanks for the information. I didn't see that hfgens was already in
> > the ENVIRON struct. I committed a version of the ftfree opcode an
> > hour or so ago that was in fgens.c and entry1.c. I'll work on pushing
> > it and ftgens and whatever opcodes that use structs in ftgen.h out to
> > an opcode plugin.
> >
> > I ended up making ftfree take both the number of the table to free as
> > well as freeTime parameter that if equal to 0 to free at opcode init,
> > and if not zero to free at deinit time. Originally, I thought the
> > instrument I am translating had a temp array that was being generated
> > and free()'d in the code and then later realized it wasn't being used.
> > Maybe it's better to simplify and just delete at deinit anyways?
> > (Maybe I'll take that option out then.)
> >
> > Do you think it's better to have an ftgentemp opcode where the table
> > is always deleted at deinit, or better to explicitly call ftfree? Is
> > there a use case where say, one instrument will generate a wavetable
> > and other instruments will use it for a while, then that instrument is
> > called again to generate a new ftable and free the old one? Hmm...
> > maybe not, as you could always just overwrite a table assigned to a
> > global var.
> >
> > Okay, sounds like an ftgentemp would be a good solution to all of
> > this. I'll remove the ftfree opcode I put in and redo it all as an
> > opcode plugin.
> >
> > Thanks!
> > steven
> >
> >
> > On 8/3/05, Istvan Varga <[hidden email]> wrote:
> > > For freeing a table with a known number, you can just use csound->hfgens()
> > > with a negative table number which will request deleting the table, and
> > > this should work from plugins. Alternatively, it may make sense to write
> > > a version of the ftgen opcode that automatically deletes the table at
> > > note deinit. It should be possible to implement that opcode as a plugin
> > > (actually, ftgen may be moved out of fgens.c as well).
> > >
> > > Steven Yi wrote:
> > >
> > > > I'm working on ftree now and am putting it in fgens.c and adding a
> > > > struct to ftgen.h, and plan to add it to entry1.c. or entry2.c,
> > > > wherever ftgen is at. The reason I'm doing this within csound and not
> > > > as a plugin is that I haven't found any API functions which can do
> > > > this. I'm using the code from hfgens:
> > > >
> > > > if (ff->fno > csound->maxfnum ||
> > > > (ftp = csound->flist[ff->fno]) == NULL) {
> > > > fterror(csound, ff, Str("ftable does not exist"));
> > > > return -1;
> > > > }
> > > > csound->flist[ff->fno] = NULL;
> > > > mfree(csound, (void*) ftp);
> > > >
> > > > (with the ff->fno coming from *p instead) to free the table. Does
> > > > this all sound alright or is there an API way to do this? (And if not,
> > > > should there be?)
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > > informative Webcasts and more! Get everything you need to get up to
> > > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > > _______________________________________________
> > > Csound-devel mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/csound-devel
> > >
> >
>

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. <a href="http://ads.osdn.com/?ad_idt77&alloc_id492&op=click">http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

john ffitch

Re: ftfree

In reply to this post by Istvan Varga

I thought one can also delete a table with event, giving an empty definition?
==John ffitch

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Steven Yi

Re: ftfree

I like that the ftable will clean itself up and timed exactly at note
deinitialization, and I think that I prefer to have it in an opcode as
the intention then is very clearn in the code and syntax-wise would
also be less Csound code to write within the instrument body.

Either way, it seems Istvan has gone and done the job I stopped on and
has moved out the opcodes to its own library, as well as left in
ftfree and created ftgentmp. Also by looking at his code I realized I
did the code incorrectly anyways doing it the old way with the 4th
function pointer in the OENTRY instead of the new
RegisterDeinitCallback. Thanks very much Istvan for this, it's very
useful to me and I appreciate it!

steven

On 8/3/05, [hidden email] <[hidden email]> wrote:

> I thought one can also delete a table with event, giving an empty definition?
> ==John ffitch
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Csound-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. <a href="http://ads.osdn.com/?ad_idt77&alloc_id492&op=click">http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Steven Yi

Re: ftfree

Hi Richard,

I too very much enjoy the legato feature of csound (I learned a great
deal from your Csound Book chapter when I first went to learn how to
use it!), and since Istvan left in the ftfree, I think it will be no
problem to only deallocate at the last note. I know with my
instruments that use tied notes, it can detect if it's the first note
of the sequence (tival == false and p3 < 0) so one could use ftgen
with that note, and then check if tival == true and p3 > 0 to detect
the end note of the sequence and call ftfree. If not a tied note at
all, then could just use ftgentmp.

steven

On 8/3/05, Richard Dobson <[hidden email]> wrote:

> This will be a useful facility: bearing in mind one of my interests, will this
> auto-deallocate work OK with legato notes (neg p3)? I am just speculating here,
> but it is possible one may want the ftable to survive until the end of the last
> note in a legato sequence.
>
>
> Richard Dobson
>
>
> Steven Yi wrote:
>
> > I like that the ftable will clean itself up and timed exactly at note
> > deinitialization, and I think that I prefer to have it in an opcode as
> > the intention then is very clearn in the code and syntax-wise would
> > also be less Csound code to write within the instrument body.
> >
> > Either way, it seems Istvan has gone and done the job I stopped on and
> > has moved out the opcodes to its own library, as well as left in
> > ftfree and created ftgentmp. Also by looking at his code I realized I
> > did the code incorrectly anyways doing it the old way with the 4th
> > function pointer in the OENTRY instead of the new
> > RegisterDeinitCallback. Thanks very much Istvan for this, it's very
> > useful to me and I appreciate it!
> >
> > steven
> >
> >
> >
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Csound-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Istvan Varga

Re: ftfree

In reply to this post by Steven Yi

Richard Dobson wrote:

> This will be a useful facility: bearing in mind one of my interests,
> will this auto-deallocate work OK with legato notes (neg p3)? I am just
> speculating here, but it is possible one may want the ftable to survive
> until the end of the last note in a legato sequence.

The deinit callback is called by deact() when the note is deactivated
and removed from the list of active instrument instances. This does not
happen in the case of "tied" notes, so the callback is really only called
at the end of the last note.
However, one should be careful about using this facility with tie/reinit,
as for every successful call of csound->RegisterDeinitCallback(), there
will be one call to the registered function, meaning that the callback
registration will accumulate.

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Istvan Varga

Re: ftfree

In reply to this post by Steven Yi

Steven Yi wrote:

> I too very much enjoy the legato feature of csound (I learned a great
> deal from your Csound Book chapter when I first went to learn how to
> use it!), and since Istvan left in the ftfree, I think it will be no
> problem to only deallocate at the last note. I know with my
> instruments that use tied notes, it can detect if it's the first note
> of the sequence (tival == false and p3 < 0) so one could use ftgen
> with that note, and then check if tival == true and p3 > 0 to detect
> the end note of the sequence and call ftfree. If not a tied note at
> all, then could just use ftgentmp.

You can also skip ftgentmp with tigoto - it will then create one table
at the beginning of the first note, and delete it when the last note in
the tied sequence is deactivated. Otherwise, it creates a new table on
every new tied note, and deletes all at once at the end of the last note.

By the way, ftgentmp currently only deletes tables with an automatic
number (p1=0); should this be changed ?

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Jean Piché

Questions for developpers re: Cecilia & CS5

In reply to this post by Istvan Varga

I have not really been following the disussions in the group so the
answers to my questions may already be known. I have been working on
a host of pretty nice modules for the next release of Cecilia and
would love to port to CS5 as soon as feasible.

How close are we to a bullet-proof (as opposed to canonball-proof)
OSX release?

1- Are the Unix pipelines the same as in the CS4 implementation (-L
flag) and are they functional now?

2- Is the launch argument structure the same as in CS4?

3- Are there many deprecated opcodes?

4- Are there substantial differences in how the orchestra and score
codes are specified?

Thank you all in advance!

hope everyone is having a wonderful summer...

jp

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Steven Yi

Re: ftfree

In reply to this post by Istvan Varga

Hi Istvan,

Thanks for the tip with tigoto; I didn't think of it that way as the
legato instruments I had put together need to know last note status
for doing it's envelopes correctly and so I never really used tigoto
and instead used tival. For this case though it seems quite handy!

As for ftgentmp, I'm not sure what to do with non-automatic numbers.
I've never used ftgen with a requested ftable number as I think it's
usefulness lies in auto-generating an ftable number and referencing
the returned table number from instruments by variable name, which is
descriptive. Since I can't even imagine a reason to use requested
ftable numbers, I'm not sure what one would want to do in this case.
Maybe ftgentmp shouldn't take in a requested table number at all and
use 0 in the underlying call to hfgens always?

steven

On 8/3/05, Istvan Varga <[hidden email]> wrote:

> Steven Yi wrote:
>
> > I too very much enjoy the legato feature of csound (I learned a great
> > deal from your Csound Book chapter when I first went to learn how to
> > use it!), and since Istvan left in the ftfree, I think it will be no
> > problem to only deallocate at the last note. I know with my
> > instruments that use tied notes, it can detect if it's the first note
> > of the sequence (tival == false and p3 < 0) so one could use ftgen
> > with that note, and then check if tival == true and p3 > 0 to detect
> > the end note of the sequence and call ftfree. If not a tied note at
> > all, then could just use ftgentmp.
>
> You can also skip ftgentmp with tigoto - it will then create one table
> at the beginning of the first note, and delete it when the last note in
> the tied sequence is deactivated. Otherwise, it creates a new table on
> every new tied note, and deletes all at once at the end of the last note.
>
> By the way, ftgentmp currently only deletes tables with an automatic
> number (p1=0); should this be changed ?
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Csound-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

Anthony Kozar

Re: Questions for developpers re: Cecilia & CS5

In reply to this post by Jean Piché

Hi Jean,

I will answer the questions that I know how to.

On 8/3/05 3:42 PM, Jean Piché <[hidden email]> etched in stone:

> 1- Are the Unix pipelines the same as in the CS4 implementation (-L
> flag) and are they functional now?

I would think this should work. But I have not tested it myself. If it
does not work, it is probably just a matter of fixing some #ifdefs.

> 2- Is the launch argument structure the same as in CS4?

Most of the command-line arguments are the same. There are several new ones
but the ones you need to look out for are real-time audio and midi flags.
These take many new arguments that can specify devices by name, etc.

> 3- Are there many deprecated opcodes?

I don't think so. One goal of Cs5 is 100% backwards compatibility with Cs4
orchestras. There are many new opcodes though including syncing up with
some of the "missing" opcodes that were previously only in CsoundAV and
MacCsound.

> 4- Are there substantial differences in how the orchestra and score
> codes are specified?

No real changes here (that I am aware of). Istvan did add a new variable
type (S-type for string variables). There are many new and significant
opcodes for fsigs (the streaming phase vocoder type), so if Cecilia does not
have good support for that, now might be a good time to look at it.

In general the most significant changes from Cecilia's point of view might
be that Csound no longer has to be run as a command-line program and that
many opcodes will now be in separate, loadable libraries. Csound 5 will be
distributed as a shared library that any program can interface with
directly. While you can continue to "shell out" to csound from Cecilia, it
is possible that you would gain significant advantages by creating a
Tcl-wrapper for the Csound C API, and then making calls to the library in
your Tcl code.

As far as the opcodes go, maintaining Cecilia's context-sensitive help might
be more challenging with so many opcodes being dynamically loaded. I have
made brief arguments before for some kind of introspection in the Csound API
or metadata in the opcode libraries themselves so that hosts such as Cecilia
will always be "up-to-date" with whatever opcode libraries are installed in
a particular user's system. I do not think that there has been any progress
on that front though.

Anthony Kozar
[hidden email]
http://akozar.spymac.net/

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

David Akbari

Re: Questions for developpers re: Cecilia & CS5

On Aug 3, 2005, at 7:41 PM, Anthony Kozar wrote:
> so that hosts such as Cecilia will always be "up-to-date" with
> whatever opcode libraries are installed in a particular user's system.

Could there exist the potential for a user to add manual entries /
contextual help when necessary? Maybe just building an interface for
this functionality... Tcl/Tk would be great for that. Java could also
be a good choice.

-David

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Andres Cabrera-3

Re: Questions for developpers re: Cecilia & CS5

In reply to this post by Anthony Kozar

Hi,
On Wed, 2005-08-03 at 18:41, Anthony Kozar wrote:

> As far as the opcodes go, maintaining Cecilia's context-sensitive help might
> be more challenging with so many opcodes being dynamically loaded. I have
> made brief arguments before for some kind of introspection in the Csound API
> or metadata in the opcode libraries themselves so that hosts such as Cecilia
> will always be "up-to-date" with whatever opcode libraries are installed in
> a particular user's system. I do not think that there has been any progress
> on that front though.

I think the blue way of doing it is very good, using the html help. That
way when the html help is updated, 'blue documentation' is updated as
well.
Andres

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Anthony Kozar

Re: Questions for developpers re: Cecilia & CS5

What I was referring to as "context-sensitive help" is Cecilia's ability to
show the syntax for an opcode as you are typing. (Once you type the opcode
name, it shows the arguments).

Even if this information could be extracted on-the-fly from the manual, the
chief problem is the potential proliferation of plugin opcodes from multiple
authors/sources that will not be integrated into the Csound distribution or
the manual. I expect with Csound 5 that many people will start distributing
their own plugins and I would like for there to be a standard way for a host
program to identify which opcodes are in the user's system, what their
syntax is (with meaningful parameter names), maybe even a short
documentation string for each opcode. All of this information should be
embedded in the compiled plugins in my opinion.

Anthony

On 8/4/05 9:06 AM, Andres Cabrera <[hidden email]> etched in stone:

> I think the blue way of doing it is very good, using the html help. That
> way when the html help is updated, 'blue documentation' is updated as
> well.
> Andres

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Jean Piché

Re: Questions for developpers re: Cecilia & CS5

a simple registrar could be generated that holds opcode names and
syntax. I am not certain how this would be done, but a simple text
file holding this information could be scanned by Cecilia. It could
rebuild its tables automatically on each launch. From my end, that's
easily done and would indeed allow to keep the opcode fly-over
feature of Cecilia always up to date, no matter how many libs are
there. As you suggest, if name, args and comments are obligatory in
DLLs, it should be easy to implement...

links to the manual, which Cecilia also supprts, are slightly
different, since you have to link to a specific html page.. I have
written a tcl script that scans the manual's quickref page and
generates the table needed for manual references within the Cecilia
editor...

j

Le 05-08-04 à 13:50, Anthony Kozar a écrit :

> What I was referring to as "context-sensitive help" is Cecilia's
> ability to
> show the syntax for an opcode as you are typing. (Once you type
> the opcode
> name, it shows the arguments).
>
> Even if this information could be extracted on-the-fly from the
> manual, the
> chief problem is the potential proliferation of plugin opcodes from
> multiple
> authors/sources that will not be integrated into the Csound
> distribution or
> the manual. I expect with Csound 5 that many people will start
> distributing
> their own plugins and I would like for there to be a standard way
> for a host
> program to identify which opcodes are in the user's system, what their
> syntax is (with meaningful parameter names), maybe even a short
> documentation string for each opcode. All of this information
> should be
> embedded in the compiled plugins in my opinion.
>
> Anthony
>
> On 8/4/05 9:06 AM, Andres Cabrera <[hidden email]> etched in
> stone:
>
>
>> I think the blue way of doing it is very good, using the html
>> help. That
>> way when the html help is updated, 'blue documentation' is updated as
>> well.
>> Andres
>>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/
> bsce5sf
> _______________________________________________
> Csound-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>

Steven Yi

Re: Questions for developpers re: Cecilia & CS5

Hi All,

Just a note, I think the quickref page is woefully out of date and
needs to be updated. Perhaps a utility should be made sometime that
will read in all reference entries and grab their syntax's, sort them,
and write out the quickref. Either way, unfortunately at this moment,
it is not a good reflection of the csound5 changes.

steven

p.s. - I too would like to figure out a good solution to this as for
blue I am reading in an XML file I put together by hand originally and
had had help in updating by users, and it too now is out of date.

On 8/4/05, Jean Piché <[hidden email]> wrote:

>
> a simple registrar could be generated that holds opcode names and
> syntax. I am not certain how this would be done, but a simple text
> file holding this information could be scanned by Cecilia. It could
> rebuild its tables automatically on each launch. From my end, that's
> easily done and would indeed allow to keep the opcode fly-over
> feature of Cecilia always up to date, no matter how many libs are
> there. As you suggest, if name, args and comments are obligatory in
> DLLs, it should be easy to implement...
>
> links to the manual, which Cecilia also supprts, are slightly
> different, since you have to link to a specific html page.. I have
> written a tcl script that scans the manual's quickref page and
> generates the table needed for manual references within the Cecilia
> editor...
>
> j
>
>
>
>
> Le 05-08-04 à 13:50, Anthony Kozar a écrit :
>
> > What I was referring to as "context-sensitive help" is Cecilia's
> > ability to
> > show the syntax for an opcode as you are typing. (Once you type
> > the opcode
> > name, it shows the arguments).
> >
> > Even if this information could be extracted on-the-fly from the
> > manual, the
> > chief problem is the potential proliferation of plugin opcodes from
> > multiple
> > authors/sources that will not be integrated into the Csound
> > distribution or
> > the manual. I expect with Csound 5 that many people will start
> > distributing
> > their own plugins and I would like for there to be a standard way
> > for a host
> > program to identify which opcodes are in the user's system, what their
> > syntax is (with meaningful parameter names), maybe even a short
> > documentation string for each opcode. All of this information
> > should be
> > embedded in the compiled plugins in my opinion.
> >
> > Anthony
> >
> > On 8/4/05 9:06 AM, Andres Cabrera <[hidden email]> etched in
> > stone:
> >
> >
> >> I think the blue way of doing it is very good, using the html
> >> help. That
> >> way when the html help is updated, 'blue documentation' is updated as
> >> well.
> >> Andres
> >>
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams *
> > Testing & QA
> > Security * Process Improvement & Measurement * http://www.sqe.com/
> > bsce5sf
> > _______________________________________________
> > Csound-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> >
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Csound-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

Jean Piché

Re: Questions for developpers re: Cecilia & CS5

__________________________________________
http://jeanpiche.com

On 05-08-04, at 14:15, Steven Yi wrote:

> Hi All,
>
> Just a note, I think the quickref page is woefully out of date and
> needs to be updated. Perhaps a utility should be made sometime that
> will read in all reference entries and grab their syntax's, sort them,
> and write out the quickref. Either way, unfortunately at this moment,
> it is not a good reflection of the csound5 changes.

I have a tcl script that does this and it is now current with Kevin's
manual. Seems te QuickRef in Kevin's manual contains everything in the
manual, but i may be mistaken.

If everyone can agree that all DLLs shoudl contain a coded entry
reflectibg its contents then this can be done:

1- Retool the -z command argument and have it dump everything from all
DLLs. I wouldn;t know how to do this.

2- Pipe to a text file.

3- From the host (Cecilia or Blue), parse the text file with a script
to generate tables needed by* the host.

For the on-line manual (i haven't followed the discussions on that
topic), it depends how the new manual is done.. is the standard still
html? and is Kevin's the basis for it? What I do (in a tcl script) is
to scan the QuickRef and lift the html links and link those to the
opcode registry in Cecilia. That , of course means that the manual is
kept in a way that is congruent with the automatically generated list
of opcodes from an eventually revised -z flag

j

> steven
>
> p.s. - I too would like to figure out a good solution to this as for
> blue I am reading in an XML file I put together by hand originally and
> had had help in updating by users, and it too now is out of date.
>
>
> On 8/4/05, Jean Piché <[hidden email]> wrote:
>>
>> a simple registrar could be generated that holds opcode names and
>> syntax. I am not certain how this would be done, but a simple text
>> file holding this information could be scanned by Cecilia. It could
>> rebuild its tables automatically on each launch. From my end, that's
>> easily done and would indeed allow to keep the opcode fly-over
>> feature of Cecilia always up to date, no matter how many libs are
>> there. As you suggest, if name, args and comments are obligatory in
>> DLLs, it should be easy to implement...
>>
>> links to the manual, which Cecilia also supprts, are slightly
>> different, since you have to link to a specific html page.. I have
>> written a tcl script that scans the manual's quickref page and
>> generates the table needed for manual references within the Cecilia
>> editor...
>>
>> j
>>
>>
>>
>>
>> Le 05-08-04 à 13:50, Anthony Kozar a écrit :
>>
>>> What I was referring to as "context-sensitive help" is Cecilia's
>>> ability to
>>> show the syntax for an opcode as you are typing. (Once you type
>>> the opcode
>>> name, it shows the arguments).
>>>
>>> Even if this information could be extracted on-the-fly from the
>>> manual, the
>>> chief problem is the potential proliferation of plugin opcodes from
>>> multiple
>>> authors/sources that will not be integrated into the Csound
>>> distribution or
>>> the manual. I expect with Csound 5 that many people will start
>>> distributing
>>> their own plugins and I would like for there to be a standard way
>>> for a host
>>> program to identify which opcodes are in the user's system, what
>>> their
>>> syntax is (with meaningful parameter names), maybe even a short
>>> documentation string for each opcode. All of this information
>>> should be
>>> embedded in the compiled plugins in my opinion.
>>>
>>> Anthony
>>>
>>> On 8/4/05 9:06 AM, Andres Cabrera <[hidden email]> etched in
>>> stone:
>>>
>>>
>>>> I think the blue way of doing it is very good, using the html
>>>> help. That
>>>> way when the html help is updated, 'blue documentation' is updated
>>>> as
>>>> well.
>>>> Andres
>>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>>> Practices
>>> Agile & Plan-Driven Development * Managing Projects & Teams *
>>> Testing & QA
>>> Security * Process Improvement & Measurement * http://www.sqe.com/
>>> bsce5sf
>>> _______________________________________________
>>> Csound-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>> Practices
>> Agile & Plan-Driven Development * Managing Projects & Teams * Testing
>> & QA
>> Security * Process Improvement & Measurement *
>> http://www.sqe.com/bsce5sf
>> _______________________________________________
>> Csound-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing
> & QA
> Security * Process Improvement & Measurement *
> http://www.sqe.com/bsce5sf
> _______________________________________________
> Csound-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

Steven Yi

Re: Questions for developpers re: Cecilia & CS5

The current Canonical Csound manual was directly based on Kevin's ACRM
work, converted from his DocBook SGML to DocBook XML. If you have a
TCL script for lifting the values from the ACRM, it should work
exactly the same with CCRM.

As for Csound's -z and -z1, these already can show the opcodes from
plugin libraries, but these options have never shown the names of
arguments, only Csound's internal argument types which are not very
descriptive of their usage.

steven

On 8/4/05, Jean Piche <[hidden email]> wrote:

>
>
> __________________________________________
> http://jeanpiche.com
>
>
> On 05-08-04, at 14:15, Steven Yi wrote:
>
> > Hi All,
> >
> > Just a note, I think the quickref page is woefully out of date and
> > needs to be updated. Perhaps a utility should be made sometime that
> > will read in all reference entries and grab their syntax's, sort them,
> > and write out the quickref. Either way, unfortunately at this moment,
> > it is not a good reflection of the csound5 changes.
>
> I have a tcl script that does this and it is now current with Kevin's
> manual. Seems te QuickRef in Kevin's manual contains everything in the
> manual, but i may be mistaken.
>
> If everyone can agree that all DLLs shoudl contain a coded entry
> reflectibg its contents then this can be done:
>
> 1- Retool the -z command argument and have it dump everything from all
> DLLs. I wouldn;t know how to do this.
>
> 2- Pipe to a text file.
>
> 3- From the host (Cecilia or Blue), parse the text file with a script
> to generate tables needed by* the host.
>
> For the on-line manual (i haven't followed the discussions on that
> topic), it depends how the new manual is done.. is the standard still
> html? and is Kevin's the basis for it? What I do (in a tcl script) is
> to scan the QuickRef and lift the html links and link those to the
> opcode registry in Cecilia. That , of course means that the manual is
> kept in a way that is congruent with the automatically generated list
> of opcodes from an eventually revised -z flag
>
>
> j
>
>
>
> > steven
> >
> > p.s. - I too would like to figure out a good solution to this as for
> > blue I am reading in an XML file I put together by hand originally and
> > had had help in updating by users, and it too now is out of date.
> >
> >
> > On 8/4/05, Jean Piché <[hidden email]> wrote:
> >>
> >> a simple registrar could be generated that holds opcode names and
> >> syntax. I am not certain how this would be done, but a simple text
> >> file holding this information could be scanned by Cecilia. It could
> >> rebuild its tables automatically on each launch. From my end, that's
> >> easily done and would indeed allow to keep the opcode fly-over
> >> feature of Cecilia always up to date, no matter how many libs are
> >> there. As you suggest, if name, args and comments are obligatory in
> >> DLLs, it should be easy to implement...
> >>
> >> links to the manual, which Cecilia also supprts, are slightly
> >> different, since you have to link to a specific html page.. I have
> >> written a tcl script that scans the manual's quickref page and
> >> generates the table needed for manual references within the Cecilia
> >> editor...
> >>
> >> j
> >>
> >>
> >>
> >>
> >> Le 05-08-04 à 13:50, Anthony Kozar a écrit :
> >>
> >>> What I was referring to as "context-sensitive help" is Cecilia's
> >>> ability to
> >>> show the syntax for an opcode as you are typing. (Once you type
> >>> the opcode
> >>> name, it shows the arguments).
> >>>
> >>> Even if this information could be extracted on-the-fly from the
> >>> manual, the
> >>> chief problem is the potential proliferation of plugin opcodes from
> >>> multiple
> >>> authors/sources that will not be integrated into the Csound
> >>> distribution or
> >>> the manual. I expect with Csound 5 that many people will start
> >>> distributing
> >>> their own plugins and I would like for there to be a standard way
> >>> for a host
> >>> program to identify which opcodes are in the user's system, what
> >>> their
> >>> syntax is (with meaningful parameter names), maybe even a short
> >>> documentation string for each opcode. All of this information
> >>> should be
> >>> embedded in the compiled plugins in my opinion.
> >>>
> >>> Anthony
> >>>
> >>> On 8/4/05 9:06 AM, Andres Cabrera <[hidden email]> etched in
> >>> stone:
> >>>
> >>>
> >>>> I think the blue way of doing it is very good, using the html
> >>>> help. That
> >>>> way when the html help is updated, 'blue documentation' is updated
> >>>> as
> >>>> well.
> >>>> Andres
> >>>>
> >>>
> >>>
> >>>
> >>> -------------------------------------------------------
> >>> SF.Net email is Sponsored by the Better Software Conference & EXPO
> >>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> >>> Practices
> >>> Agile & Plan-Driven Development * Managing Projects & Teams *
> >>> Testing & QA
> >>> Security * Process Improvement & Measurement * http://www.sqe.com/
> >>> bsce5sf
> >>> _______________________________________________
> >>> Csound-devel mailing list
> >>> [hidden email]
> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> >>>
> >>>
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> SF.Net email is Sponsored by the Better Software Conference & EXPO
> >> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> >> Practices
> >> Agile & Plan-Driven Development * Managing Projects & Teams * Testing
> >> & QA
> >> Security * Process Improvement & Measurement *
> >> http://www.sqe.com/bsce5sf
> >> _______________________________________________
> >> Csound-devel mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
> >>
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams * Testing
> > & QA
> > Security * Process Improvement & Measurement *
> > http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Csound-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Csound-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>