I think this is good. The opcode is focused on just getting data out of the 
image, so you can do whatever you want with it in Csound. That's the correct 
approach - separate out the image parts of the problem from the music parts.

This makes it also possible to use image files to store time/frequency 
analyses. They could be in any aspect ratio.

I think, however, that it might be useful to have an option to have kx and 
ky in column and row indexes as well, with an info opcode to tell you how 
many there are.

How long does it sit in the score sorting phase? Are you trying to work in 
real time, or do you render to a soundfile?

You could probably use a RAM disk - copy the image to a RAM disk and also 
put the score file there as well. Ought to speed it up a bit, but modern 
disks are pretty fast.

Regards,
Mike

----- Original Message ----- 
From: "Cesare Marilungo" 
To: 
Sent: Saturday, November 17, 2007 7:18 PM
Subject: [Csnd] imagein opcode (was Re: Re: Re: Poor man's MetaSynth)


> Thank you Michael. Using fractional insnos allows a better rendering of 
> image rows. My idea was more like some sort of granular synthesis.
>
> The problem is that even with this solution the size of the score would be 
> as big. With big score files csound sits when at "sorting score ...".
>
> Anyway, in the meanwhile I am experimenting on the csound side and I wrote 
> my first opcode.
>
> Usage example:
>
> kred, kgreen, kblue imagein "image.png", kx, ky
>
> where kx and ky are from 0.0 to 1.0 ( x is from left, y is from top) so 
> you don't need to specify the image size. Color values are 0.0 to 1.0 too. 
> The image can be whatever format is supported by Imlib.
>
> http://www.cesaremarilungo.com/download/csound/imagePlugin.tar.gz
>
> Ciao,
>
> - c.
>
> Michael Gogins wrote:
>>> From: Cesare Marilungo 
>>> Sent: Nov 16, 2007 2:15 PM
>>> To: csound@lists.bath.ac.uk
>>> Subject: [Csnd] Re: Re: Poor man's MetaSynth (was: Re: Re: Re: Re: Re: 
>>> Re: [ot] - Old Moog 900 Series Demo)
>>>
>>> The first idea makes sense, now that I think of it, but it would mean 
>>> throwing away two evenings of studying the gimp documentation and coding 
>>> a proof of concept (which is ready btw). :-)
>>>
>>> The second makes sense too. But isn't the csound score already a custom 
>>> data file? I mean is there something I can't do with it that would be 
>>> better addressed by an instrument opcode?
>>>
>>
>> You were complaining about the volume of data in the score file. Moving 
>> that volume of data to a custom file would possibly make sense.
>>
>> Alternatively, you could tie the pixels on the same row as follows. 
>> Fractional insnos mean that the next note for insno.fraction goes to the 
>> instance first created with insno.fraction. Musically this is simply a 
>> tied note.
>>
>> p1 = insno.pixelrow ; e.g. 1.00001 first row, 1.00002 second row
>> p2 = timefactor * pixelcolumn ; time
>> p3 = -1 ; Keep playing across the pixel columns
>> p4 = pitchfunction(pixelrow) ; pitch or frequency
>> p5 = amplitudefunction(rgb of row, current column) ; amplitude at 
>> beginning of note
>> p6 = amplitudefunction(rgb of row, next column) ; amplitude at end of 
>> note, i.e. beginning of next note
>> etc.
>>
>> I used this scheme with hetro analysis files (with as many partials as I 
>> could get). I read the analysis file with a Java program, and wrote a 
>> .sco file in a format similiar to the above. With hetro the "lines" or 
>> "rows" change in frequency, with an image file the rows have a fixed 
>> frequency, but really it is pretty much the same in terms of resynthesis.
>>
>> Instead of using adsyn I used an oscillator very like what you propose. 
>> My solution guarantees smooth changes in amplitude along a row of pixels 
>> if you setup a linen between the amplitude of the current column and the 
>> next column, this implementing linear interpolation of amplitude from 
>> column to column. You could even pass the next 3 or 4 columns in, and use 
>> cubic or spline interpolation for the amplitude changes.
>>
>> My scheme makes it possible to render the image over a longer or shorter 
>> period of time, without introducing artifacts -- this is why I used it, I 
>> wanted long time stretches. I also wanted to manipulate the "sound 
>> pixels" the same way I was manipulating other notes in the Silence class 
>> system.
>>
>> At any rate, you start up as many instances of the same instrument as you 
>> have rows of pixels, and they just keep playing at lower or higher 
>> amplitudes through all the columns of pixels till you get the right edge 
>> of the image.
>>
>> Hope this is helpful,
>> Mike
>>
>>
>>
>>
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
>> csound"
>>
>>
>>
>
>
> -- 
> www.cesaremarilungo.com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 

The performance issue is not with this opcode I just wrote. It is when I 
try to parse the big score file outputted by the Gimp plugin I was 
writing. The plugin itself is fast when writing the file. Is csound that 
can't handle it.

Consider that an image larger that 300x300 that produces a score as big 
as 5,6 Mb takes several minutes to parse. I tried with a 800x600 image 
(so the score was >30-40Mb) and after two hours or more it was still 
sitted there so I killed it.

About the opcode:

Imlib takes care of everything. IIRC it caches the image too, so 
performance is not an issue.

If you try it with this code:

kval linseg 0, p3, 1
kred, kgreen, kblue imagein "image.png", kval, 0

printk 0, kred
printk 0, kgreen
printk 0, kblue

basically you're reading the first row of the image. There shouldn't any 
problem at audio rate too. I might try it.

- c.

Michael Gogins wrote:
> I think this is good. The opcode is focused on just getting data out of the 
> image, so you can do whatever you want with it in Csound. That's the correct 
> approach - separate out the image parts of the problem from the music parts.
>
> This makes it also possible to use image files to store time/frequency 
> analyses. They could be in any aspect ratio.
>
> I think, however, that it might be useful to have an option to have kx and 
> ky in column and row indexes as well, with an info opcode to tell you how 
> many there are.
>
> How long does it sit in the score sorting phase? Are you trying to work in 
> real time, or do you render to a soundfile?
>
> You could probably use a RAM disk - copy the image to a RAM disk and also 
> put the score file there as well. Ought to speed it up a bit, but modern 
> disks are pretty fast.
>
> Regards,
> Mike
>
> ----- Original Message ----- 
> From: "Cesare Marilungo" 
> To: 
> Sent: Saturday, November 17, 2007 7:18 PM
> Subject: [Csnd] imagein opcode (was Re: Re: Re: Poor man's MetaSynth)
>
>
>   
>> Thank you Michael. Using fractional insnos allows a better rendering of 
>> image rows. My idea was more like some sort of granular synthesis.
>>
>> The problem is that even with this solution the size of the score would be 
>> as big. With big score files csound sits when at "sorting score ...".
>>
>> Anyway, in the meanwhile I am experimenting on the csound side and I wrote 
>> my first opcode.
>>
>> Usage example:
>>
>> kred, kgreen, kblue imagein "image.png", kx, ky
>>
>> where kx and ky are from 0.0 to 1.0 ( x is from left, y is from top) so 
>> you don't need to specify the image size. Color values are 0.0 to 1.0 too. 
>> The image can be whatever format is supported by Imlib.
>>
>> http://www.cesaremarilungo.com/download/csound/imagePlugin.tar.gz
>>
>> Ciao,
>>
>> - c.
>>
>> Michael Gogins wrote:
>>     
>>>> From: Cesare Marilungo 
>>>> Sent: Nov 16, 2007 2:15 PM
>>>> To: csound@lists.bath.ac.uk
>>>> Subject: [Csnd] Re: Re: Poor man's MetaSynth (was: Re: Re: Re: Re: Re: 
>>>> Re: [ot] - Old Moog 900 Series Demo)
>>>>
>>>> The first idea makes sense, now that I think of it, but it would mean 
>>>> throwing away two evenings of studying the gimp documentation and coding 
>>>> a proof of concept (which is ready btw). :-)
>>>>
>>>> The second makes sense too. But isn't the csound score already a custom 
>>>> data file? I mean is there something I can't do with it that would be 
>>>> better addressed by an instrument opcode?
>>>>
>>>>         
>>> You were complaining about the volume of data in the score file. Moving 
>>> that volume of data to a custom file would possibly make sense.
>>>
>>> Alternatively, you could tie the pixels on the same row as follows. 
>>> Fractional insnos mean that the next note for insno.fraction goes to the 
>>> instance first created with insno.fraction. Musically this is simply a 
>>> tied note.
>>>
>>> p1 = insno.pixelrow ; e.g. 1.00001 first row, 1.00002 second row
>>> p2 = timefactor * pixelcolumn ; time
>>> p3 = -1 ; Keep playing across the pixel columns
>>> p4 = pitchfunction(pixelrow) ; pitch or frequency
>>> p5 = amplitudefunction(rgb of row, current column) ; amplitude at 
>>> beginning of note
>>> p6 = amplitudefunction(rgb of row, next column) ; amplitude at end of 
>>> note, i.e. beginning of next note
>>> etc.
>>>
>>> I used this scheme with hetro analysis files (with as many partials as I 
>>> could get). I read the analysis file with a Java program, and wrote a 
>>> .sco file in a format similiar to the above. With hetro the "lines" or 
>>> "rows" change in frequency, with an image file the rows have a fixed 
>>> frequency, but really it is pretty much the same in terms of resynthesis.
>>>
>>> Instead of using adsyn I used an oscillator very like what you propose. 
>>> My solution guarantees smooth changes in amplitude along a row of pixels 
>>> if you setup a linen between the amplitude of the current column and the 
>>> next column, this implementing linear interpolation of amplitude from 
>>> column to column. You could even pass the next 3 or 4 columns in, and use 
>>> cubic or spline interpolation for the amplitude changes.
>>>
>>> My scheme makes it possible to render the image over a longer or shorter 
>>> period of time, without introducing artifacts -- this is why I used it, I 
>>> wanted long time stretches. I also wanted to manipulate the "sound 
>>> pixels" the same way I was manipulating other notes in the Silence class 
>>> system.
>>>
>>> At any rate, you start up as many instances of the same instrument as you 
>>> have rows of pixels, and they just keep playing at lower or higher 
>>> amplitudes through all the columns of pixels till you get the right edge 
>>> of the image.
>>>
>>> Hope this is helpful,
>>> Mike
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
>>> csound"
>>>
>>>
>>>
>>>       
>> -- 
>> www.cesaremarilungo.com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
>> csound" 
>>     
>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>   


-- 
www.cesaremarilungo.com