>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

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