Steven Yi wrote:
> 
> I do not think there is a convenient way to do this. I imagine one
> could the compile step, then take the CSOUND* and walk every data
> object and write it out to disk or copy to memory (depending on if you
> are trying to restart from disk or in memory).  I do not know if there
> is any technique like this in C to do a deep copy of a struct like
> there is in Java or other languages; if so, then one could do that
> with the CSOUND* and then just start processing with the reserialized
> copy or in-memory copy.
> 
> 


Cloning the tree pointed by CSOUND* or part of it, ie INSTRTXT*

http://www.csounds.com/internals/index.html

would require a complete knowledge of the internal structures.
In fact there are also a lot of pointers hanging around whose 
memory allocation size should depend on other fields.

Anyway i thought that skipping the compilation would eliminate
the need for external files. 

Another way around...

At a first glance i see that CSound code is tightly coupled
to "stdio" functions calls. Why not replacing the direct calls 
to "fopen & CO" with "pointers to functions", let's say...

virtual_fopen --> fopen
virtual_fclose --> fclose
virtual_fgetc --> fget

and so on.

This already happens for the function "FileOpen2".

The "V" functions would, by default, point to the 
classic stdio functions, but the "user" could 
hook these calls and provide his own data and/or
store output data internally (ie memory streams)

But if CSound can already handle memory files
let me know. I didn't find info about that.

-- 
View this message in context: http://www.nabble.com/Skipping-CSound-Compilation-tp21540668p21580649.html
Sent from the Csound - Dev mailing list archive at Nabble.com.


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think you should be able to embed an orc/sco intro a program.  I
know Rory's Lettuce project allows exporting a project as an
executable, and the trick done there is that a resource in the exe is
replaced with the orc/sco/csd of the project.  If you really want to
embed everything, you can use encode resources with uuencode and embed
into a CSD, then embed the CSD into an executable.

On Wed, Jan 21, 2009 at 2:40 AM, Pinball  wrote:
>
>
>
> Steven Yi wrote:
>>
>> I do not think there is a convenient way to do this. I imagine one
>> could the compile step, then take the CSOUND* and walk every data
>> object and write it out to disk or copy to memory (depending on if you
>> are trying to restart from disk or in memory).  I do not know if there
>> is any technique like this in C to do a deep copy of a struct like
>> there is in Java or other languages; if so, then one could do that
>> with the CSOUND* and then just start processing with the reserialized
>> copy or in-memory copy.
>>
>>
>
>
> Cloning the tree pointed by CSOUND* or part of it, ie INSTRTXT*
>
> http://www.csounds.com/internals/index.html
>
> would require a complete knowledge of the internal structures.
> In fact there are also a lot of pointers hanging around whose
> memory allocation size should depend on other fields.
>
> Anyway i thought that skipping the compilation would eliminate
> the need for external files.
>
> Another way around...
>
> At a first glance i see that CSound code is tigtly coupled
> to "stdio" functions calls. Why not replacing the direct calls
> to "fopen & CO" with "pointers to functions", let's say...
>
> virtual_fopen --> fopen
> virtual_fclose --> fclose
> virtual_fgetc --> fget
>
> and so on.
>
> This already happens for the function "FileOpen2".
>
> The "V" functions would, by default, point to the
> classic stdio functions, but the "user" could
> hook this calls and provide its own data and/or
> store output data internally (ie memory streams)
>
> But if CSound can already handle memory files
> let me know. I didn't find info about that.
>
> --
> View this message in context: http://www.nabble.com/Skipping-CSound-Compilation-tp21540668p21580649.html
> Sent from the Csound - Dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Steven Yi wrote:
> 
> I think you should be able to embed an orc/sco intro a program.  I
> know Rory's Lettuce project allows exporting a project as an
> executable, and the trick done there is that a resource in the exe is
> replaced with the orc/sco/csd of the project.  If you really want to
> embed everything, you can use encode resources with uuencode and embed
> into a CSD, then embed the CSD into an executable.
> 

I already have the CSD file embedded into the code.
When i have to turn it to csoundCompile i save it on 
a temporary file. 

Besides, when compiling a CSD file, CSound exports
two other temporary files, one for the score and one 
for the orchestra, and one for the sorted score and...

I could live with that, but for example, in building
a VST i find it very messy to have to hang around
with a set of external files (how about .csoundrc 
either ?)

In spite of the fact that CSound now is a DLL
(or whatever module), the initialization and
compilation parts still rely on a "stand alone" 
architecture: command line arguments, con-
figuration files, and having to explicitly read 
the "code" from an external file. I would move 
all of these parts to an interface for stand 
alone support, keeping the core generic.

BTW, i'm almost done with the virtualization 
of the stdio calls. But considering what i said 
above, it's just a patch.


-- 
View this message in context: http://www.nabble.com/Skipping-CSound-Compilation-tp21540668p21665795.html
Sent from the Csound - Dev mailing list archive at Nabble.com.


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net