I'm writing a python that package that is only a hop-skip-jump away from
being able to convert a csd file into an orc-sco pair and vice-versa. Plus,
I think there might already be a utility that does this somewhere floating
on the net.  So this part of your suggestion shouldn't be an issue.

As for renumbering instruments, scorelines, etc... Could you provide a
pseudo-code example?  I think I know what you're getting at, but I want to
make sure.

One other thing.  It might be better to skip all of the Csound GUI programs
and use a terminal window. Back in the day when I was still using windows, I
installed and used Cygwin for all my Csound needs.  It's a "Linux-like
environment" that can run csound from a command prompt.  If it works with
Jaws, then any jaws-supported text editor can be used in the creation of
csd-orc-sco files.

http://www.cygwin.com/

Best,
Jake



Jason Adams wrote:
> 
> Hey guys, I'm in Dr. B's Csound class right now and there's a student who
> is killing @ Csound but has had a lot of trouble combining his orcs/scos
> because he's blind.  Here's the situation and then I will propose a
> possible solution:
> -He's working on a Windows machine because Jaws for Windows can only read
> the old WinSound screen to him (which can only read orcs and scores, not
> .csd files)
> -The new WinSound and QuteCsound can not be read by Jaws.
> -He makes all of his music with note lists (and his music is just
> righteous)
> 
> Thus he could use (and I think all of us could benefit from) a utility
> that would merge .csd files, and orcs and scos. Ideally it would renumber
> the instruments and the corresponding score lines, and would renumber
> f-tables to accurately represent the instruments.
> 
> I understand that this may be a lot to ask and I thank you for addressing
> this issue because Csound is really something that can be used by the
> masses.  Since it's mostly text, it can be read to my friend who is
> visually impared, which other synthesis/sequencing programs cannot (due to
> the excessive GUI).  I see this as an opportunity for the community and
> program to grow, thus I implore you to ask yourself if you can help make
> this possible.  Thank you again for your considerations, and making such a
> wonderful/powerful program available and inviting.
> 
> ciao,
> Jason Adams
> 
> jadams1@berklee.net
> www.myspace.com/electronicadams
> 
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 

-- 
View this message in context: http://www.nabble.com/help-my-friend-combine-orcs-tp24722386p24723118.html
Sent from the Csound - General mailing list archive at Nabble.com.

I recognise the problem.  Years ago in my emacs mode I provided for
merging vi a database of instruments.  Merging scores is easier -- if one
uses names for instruments or uses macros.  I never got round to solving
the table numbers, but I think judicious use of macros should do most of
it.

I kow there are emacs readers as one of the emacs developers is blind. We
have a blind research studet who took my DSP class, and it was a challenge
for me, but at least his software could read LaTeX.

Might get some suggestions from Julien Claassen as how he manages (or
perhaps he does not!)

> Hey guys, I'm in Dr. B's Csound class right now and there's a student who
> is killing @ Csound but has had a lot of trouble combining his orcs/scos
> because he's blind.  Here's the situation and then I will propose a
> possible solution:
.....

> I'm writing a python that package that is only a hop-skip-jump away from
> being able to convert a csd file into an orc-sco pair and vice-versa. Plus,
> I think there might already be a utility that does this somewhere floating
> on the net.  

csound-x (on Emacs) does that.

Stef

> Ideally it would renumber the instruments and the corresponding score lines, 
 > and would renumber f-tables to accurately represent the instruments.

this is next to impossible for the general case, since the reference for 
a f-table within an orchestra is just a plain number that can be stored 
and used in many different ways, so that safely re-numbering f-tables 
requires an extensive analysis of the code. I could (maybe) implement 
that in csound-x, to some extent, but it's a lot of work...

Stef

http://www.csounds.com/journal/2006winter/encapsulatedInstruments.html

Steven Yi's excellent article on encapsulated instruments suggests ways of designing instruments to make them more portable in the first place.

Iain

________________________________
> Date: Wed, 29 Jul 2009 12:00:43 -0400
> From: jadams1@berklee.net
> To: csound@lists.bath.ac.uk
> CC: jason_adams30@hotmail.com; rboulanger@berklee.net
> Subject: [Csnd] help my friend combine orcs
>
>
>
> Hey guys, I'm in Dr. B's Csound class right now and there's a student who is killing @ Csound but has had a lot of trouble combining his orcs/scos because he's blind. Here's the situation and then I will propose a possible solution:
> -He's working on a Windows machine because Jaws for Windows can only read the old WinSound screen to him (which can only read orcs and scores, not .csd files)
> -The new WinSound and QuteCsound can not be read by Jaws.
> -He makes all of his music with note lists (and his music is just righteous)
>
> Thus he could use (and I think all of us could benefit from) a utility that would merge .csd files, and orcs and scos. Ideally it would renumber the instruments and the corresponding score lines, and would renumber f-tables to accurately represent the instruments.
>
> I understand that this may be a lot to ask and I thank you for addressing this issue because Csound is really something that can be used by the masses. Since it's mostly text, it can be read to my friend who is visually impared, which other synthesis/sequencing programs cannot (due to the excessive GUI). I see this as an opportunity for the community and program to grow, thus I implore you to ask yourself if you can help make this possible. Thank you again for your considerations, and making such a wonderful/powerful program available and inviting.
>
> ciao,
> Jason Adams
>
> jadams1@berklee.net
> www.myspace.com/electronicadams

_________________________________________________________________
Windows Live™ Hotmail®: Celebrate the moment with your favorite sports pics. Check it out.
http://www.windowslive.com/Online/Hotmail/Campaign/QuickAdd?ocid=TXT_TAGLM_WL_QA_HM_sports_photos_072009&cat=sports

Just to note, blue has a means to encapsulate ftables with instruments
such that instruments can be copied into projects with all
dependencies in tact and without clashing. The method requires
instruments use ftgen for ftables and use the special blue variable
 to append to the variable name to be used with ftgen.

Another way is to create dependent ftables in instr code. I wrote an
article on it in the Csound Journal a while back (replying on phone so
can't look it up at the moment).

However, Stephane is correct in it being near impossible to analyze
orchestras for ftable dependencies, but there are ways to create
encapsulated instruments to achieve the desired effect.

Steven

On 7/29/09, Stéphane Rollandin  wrote:
>> Ideally it would renumber the instruments and the corresponding score
>> lines,
>  > and would renumber f-tables to accurately represent the instruments.
>
> this is next to impossible for the general case, since the reference for
> a f-table within an orchestra is just a plain number that can be stored
> and used in many different ways, so that safely re-numbering f-tables
> requires an extensive analysis of the code. I could (maybe) implement
> that in csound-x, to some extent, but it's a lot of work...
>
> Stef
>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>

-- 
Sent from my mobile device

> However, Stephane is correct in it being near impossible to analyze
> orchestras for ftable dependencies, but there are ways to create
> encapsulated instruments to achieve the desired effect.

maybe we could set up a common idiom to standardize instruments sharing ?

Stef

Csound's system of tracking instruments and f-tables by numbers is seriously
dated, and there needs to be a discussion about upgrading this part of
Csound with using names and namespaces.  Not to mention, the ability to
declare something along the lines of static local tables in an instrument,
for true encapsulation .  Steven's solutions are great for the way Csound
currently works, but Csound should be able to do this without work-arounds,
conditionals, macros, etc.

A dream system would allow importing individual instruments with all
dependencies, seamlessly, from other orchestras.  That is, without having to
copy and paste.  e.g.:

from trapped.csd import instr Ivory
import udo Upconvert

I've prototyped a few scripts over the years that is in line with what I'm
proposing.  Now that I have a bit more experience under my belt, I should be
able to write Python module that does the trick.  In essence, the python
script would translate a meta-csd into csd, where the csd code is treated as
if it were byte-code, or something along those lines.

The biggest issue with this type of solution is that one would have to
preprocess their py_csd file to generate a csd file before executing.  On
the other hand, if it makes writing music easier, then why not?

Best,
Jake



Stéphane Rollandin wrote:
> 
>> However, Stephane is correct in it being near impossible to analyze
>> orchestras for ftable dependencies, but there are ways to create
>> encapsulated instruments to achieve the desired effect.
> 
> maybe we could set up a common idiom to standardize instruments sharing ?
> 
> Stef
> 
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

-- 
View this message in context: http://www.nabble.com/help-my-friend-combine-orcs-tp24722386p24726634.html
Sent from the Csound - General mailing list archive at Nabble.com.

> A dream system would allow importing individual instruments with all
> dependencies, seamlessly, from other orchestras.  That is, without having to
> copy and paste.  e.g.:
> 
> from trapped.csd import instr Ivory
> import udo Upconvert
> 
> I've prototyped a few scripts over the years that is in line with what I'm
> proposing.  Now that I have a bit more experience under my belt, I should be
> able to write Python module that does the trick.  In essence, the python
> script would translate a meta-csd into csd, where the csd code is treated as
> if it were byte-code, or something along those lines.
> 
> The biggest issue with this type of solution is that one would have to
> preprocess their py_csd file to generate a csd file before executing.  On
> the other hand, if it makes writing music easier, then why not?

again, if this kind of system is to be implemented above csound syntax, 
then we should set up a standard common idiom.

else your python script will require one format, Blue another one and 
csound-x its own... generating CSD files from scripts is easy, sharing 
instruments across systems is not.

note that we have already have this issue with real-time controls: 
csound front-ends have their own syntax for representing sliders and 
co., which can make the corresponding CSD not portable.

ending up with compositions depending on a specific front-end would be a 
step backward IMO. maybe it is time to extend the CSD format to take 
care of that. front-ends would read and write specific sections of the 
CSD giving a meta description of the composition, which would make it 
easier to analyse the instruments/table interactions, and all the 
real-time widgets stuff.


Stef

on 2009-07-30 at 13:57 Stéphane Rollandin wrote:

>ending up with compositions depending on a specific front-end would be
>a step backward IMO. maybe it is time to extend the CSD format to take 
>care of that. front-ends would read and write specific sections of the 
>CSD giving a meta description of the composition, which would make it 
>easier to analyse the instruments/table interactions, and all the 
>real-time widgets stuff.

+1 to all that

Hi,

On Thu, Jul 30, 2009 at 8:02 AM, luis jure wrote:
>
> on 2009-07-30 at 13:57 Stéphane Rollandin wrote:
>
>>ending up with compositions depending on a specific front-end would be
>>a step backward IMO. maybe it is time to extend the CSD format to take
>>care of that. front-ends would read and write specific sections of the
>>CSD giving a meta description of the composition, which would make it
>>easier to analyse the instruments/table interactions, and all the
>>real-time widgets stuff.
>
> +1 to all that
>

+1
That's why I used the MacCsound format (even thought it's not
extensible) instead of making up a new one.

I'll give some thought and make a proposal for a new csd section to
hold widgets (possibly based on the format blue uses) and possibly the
other stuff that Stephane mentions.
What exactly do you have in mind Stephane?

Cheers,
Andrés

>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



-- 


Andrés

I completely agree with the a common idiom.

I should probably come clean that I've been sketching out something along
these lines over the past month, and have a dozen or so text files of
pseudo-meta-csound syntax.  The end product I'm shooting for is something
that is still *very* familiar to us Csounders, but boosts our productivity
by auto-handling much of the things we currently do manually.  i.e.
instrument and f-table numbers, importing from other files, etc...

Extensibility is also a primary goal of this side project of mine.  For
example, being able to import a score processor that non-destructively edits
snippets of score code.

Best,
Jake





Stéphane Rollandin wrote:
> 
>> A dream system would allow importing individual instruments with all
>> dependencies, seamlessly, from other orchestras.  That is, without having
>> to
>> copy and paste.  e.g.:
>> 
>> from trapped.csd import instr Ivory
>> import udo Upconvert
>> 
>> I've prototyped a few scripts over the years that is in line with what
>> I'm
>> proposing.  Now that I have a bit more experience under my belt, I should
>> be
>> able to write Python module that does the trick.  In essence, the python
>> script would translate a meta-csd into csd, where the csd code is treated
>> as
>> if it were byte-code, or something along those lines.
>> 
>> The biggest issue with this type of solution is that one would have to
>> preprocess their py_csd file to generate a csd file before executing.  On
>> the other hand, if it makes writing music easier, then why not?
> 
> again, if this kind of system is to be implemented above csound syntax, 
> then we should set up a standard common idiom.
> 
> else your python script will require one format, Blue another one and 
> csound-x its own... generating CSD files from scripts is easy, sharing 
> instruments across systems is not.
> 
> note that we have already have this issue with real-time controls: 
> csound front-ends have their own syntax for representing sliders and 
> co., which can make the corresponding CSD not portable.
> 
> ending up with compositions depending on a specific front-end would be a 
> step backward IMO. maybe it is time to extend the CSD format to take 
> care of that. front-ends would read and write specific sections of the 
> CSD giving a meta description of the composition, which would make it 
> easier to analyse the instruments/table interactions, and all the 
> real-time widgets stuff.
> 
> 
> Stef
> 
> 
> 
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

-- 
View this message in context: http://www.nabble.com/help-my-friend-combine-orcs-tp24722386p24741245.html
Sent from the Csound - General mailing list archive at Nabble.com.

> I'll give some thought and make a proposal for a new csd section to
> hold widgets (possibly based on the format blue uses) and possibly the
> other stuff that Stephane mentions.
> What exactly do you have in mind Stephane?


hello,

sorry for the delay...

well I have no specific idea, other than the fact that we should clearly 
separate what is specific to a front-end and what is generic 
meta-information. for example values controlled by real-time widgets 
should be identified in a generic section, with upper and lower limits, 
default value, etc... while widget snapshots should probably be stored 
in other, front-end specific sections.

does that make any sense ?

Stef