Hello everyone.  I'm trying my hand at writing a cabbage instrument
similar to Menno's "ImagePlayer" for Blue.  This code is only part of
it, this specific instrument only gets called when the filename
changes, and is meant to lad the image data into arrays or tables
(haven't gotten that far yet, right now it's just counting pixels)

When I load a new image, this instrument would send out text of the
name to one channel (disname), and text of the X/Y size to another
(dispsize).

If I load an image, I see the correct size listed in those channels...
however after the loops, it reports to my debug channel that it has
gone through 13 extra passes on the Y loop.

I think the two cggoto lines should be the lines of most interest...
the X loop stops correctly where it should, but the Y loop always
gives 13 extra... regardless of the size of the image I load.  That's
why it now contains "max(0,imaxY-13)", otherwise it should have been
handled the same as X.

Any idea why this is happening and what I can do to avoid it rather
than workaround it?

; load image data
instr 3
  Sfile chnget "filename"
  iimage imageload Sfile
  imaxX, imaxY imagesize iimage
  chnset sprintfk("text(File: %s)", Sfile), "dispname"
  chnset sprintfk("text(X: %d   Y: %d)", imaxX, imaxY), "dispsize"

  kxindex init 0
  kyindex init 0
  loopy:
    kxindex = 0
  loopx:
    kxindex=kxindex+1
    cggoto (kxindex

I discovered that if I change what is calling this instrument from:
    event "i", 3, 0, .01
to
    event "i", 3, 0, .001

It loops through the correct number... and even further, if I change it to:
    event "i", 3, 0, .0001

It doesn't go through *ENOUGH* loops.  I guess I need to work out a
different method to complete the loop.

On Mon, Dec 28, 2015 at 9:45 PM, Kevin Welsh  wrote:
> Hello everyone.  I'm trying my hand at writing a cabbage instrument
> similar to Menno's "ImagePlayer" for Blue.  This code is only part of
> it, this specific instrument only gets called when the filename
> changes, and is meant to lad the image data into arrays or tables
> (haven't gotten that far yet, right now it's just counting pixels)
>
> When I load a new image, this instrument would send out text of the
> name to one channel (disname), and text of the X/Y size to another
> (dispsize).
>
> If I load an image, I see the correct size listed in those channels...
> however after the loops, it reports to my debug channel that it has
> gone through 13 extra passes on the Y loop.
>
> I think the two cggoto lines should be the lines of most interest...
> the X loop stops correctly where it should, but the Y loop always
> gives 13 extra... regardless of the size of the image I load.  That's
> why it now contains "max(0,imaxY-13)", otherwise it should have been
> handled the same as X.
>
> Any idea why this is happening and what I can do to avoid it rather
> than workaround it?
>
> ; load image data
> instr 3
>   Sfile chnget "filename"
>   iimage imageload Sfile
>   imaxX, imaxY imagesize iimage
>   chnset sprintfk("text(File: %s)", Sfile), "dispname"
>   chnset sprintfk("text(X: %d   Y: %d)", imaxX, imaxY), "dispsize"
>
>   kxindex init 0
>   kyindex init 0
>   loopy:
>     kxindex = 0
>   loopx:
>     kxindex=kxindex+1
>     cggoto (kxindex     kyindex=kyindex+1
>     cggoto (kyindex chnset sprintfk("text(counted %d %d)",kxindex,kyindex), "debug"
> endin

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Thanks Rory, but I think that either I misunderstand your code or you
misunderstand my goal.

I need to iterate through X, starting from 0 and going to the maxX for
*each separate* row on Y.  During this loop I'm going to be loading
these values with imagegetpixel into either a 2d array or some tables
(I'm not quite sure the best approach for this yet) to use them as a
data source for adsynth.  So basically, when Y is 0, X goes from 0 to
maxX reading the row... then increment Y by 1... repeat reading the
next row's X values, etc.

I could be mistaken, but I don't think your code does this... that
said, I could probably work the loop into this style of code easy
enough.

Thanks for the suggestion.  I'm done csound/cabbage for now, but I'll
try some more experimenting with it tomorrow!

On Tue, Dec 29, 2015 at 4:20 AM, Rory Walsh  wrote:
> I'm not a fan of the goto stuff so I rewrote the instrument to avoid
> them(sorry, I should have spent more time looking into why your instrument
> didn't work, but I'm still on holidays ;) Anyhow, it seems to do everything
> I'd expect here?
>
> ; load image data
> instr 3
>   iimage imageload "/home/image.png"
>   imaxX, imaxY imagesize iimage
>   prints sprintfk("X: %d   Y: %d)\n", imaxX, imaxY)
>
>   kxindex init 0
>   kyindex init 0
>
>   if kyindex         kxindex= (kxindex         kyindex= (kyindex         printks sprintfk("counted X:%d Y%d\n",kxindex,kyindex), 0
>   endif
> endin
>
> On 29 December 2015 at 03:09, Kevin Welsh  wrote:
>>
>> I discovered that if I change what is calling this instrument from:
>>     event "i", 3, 0, .01
>> to
>>     event "i", 3, 0, .001
>>
>> It loops through the correct number... and even further, if I change it
>> to:
>>     event "i", 3, 0, .0001
>>
>> It doesn't go through *ENOUGH* loops.  I guess I need to work out a
>> different method to complete the loop.
>>
>> On Mon, Dec 28, 2015 at 9:45 PM, Kevin Welsh  wrote:
>> > Hello everyone.  I'm trying my hand at writing a cabbage instrument
>> > similar to Menno's "ImagePlayer" for Blue.  This code is only part of
>> > it, this specific instrument only gets called when the filename
>> > changes, and is meant to lad the image data into arrays or tables
>> > (haven't gotten that far yet, right now it's just counting pixels)
>> >
>> > When I load a new image, this instrument would send out text of the
>> > name to one channel (disname), and text of the X/Y size to another
>> > (dispsize).
>> >
>> > If I load an image, I see the correct size listed in those channels...
>> > however after the loops, it reports to my debug channel that it has
>> > gone through 13 extra passes on the Y loop.
>> >
>> > I think the two cggoto lines should be the lines of most interest...
>> > the X loop stops correctly where it should, but the Y loop always
>> > gives 13 extra... regardless of the size of the image I load.  That's
>> > why it now contains "max(0,imaxY-13)", otherwise it should have been
>> > handled the same as X.
>> >
>> > Any idea why this is happening and what I can do to avoid it rather
>> > than workaround it?
>> >
>> > ; load image data
>> > instr 3
>> >   Sfile chnget "filename"
>> >   iimage imageload Sfile
>> >   imaxX, imaxY imagesize iimage
>> >   chnset sprintfk("text(File: %s)", Sfile), "dispname"
>> >   chnset sprintfk("text(X: %d   Y: %d)", imaxX, imaxY), "dispsize"
>> >
>> >   kxindex init 0
>> >   kyindex init 0
>> >   loopy:
>> >     kxindex = 0
>> >   loopx:
>> >     kxindex=kxindex+1
>> >     cggoto (kxindex> >     kyindex=kyindex+1
>> >     cggoto (kyindex> > chnset sprintfk("text(counted %d %d)",kxindex,kyindex), "debug"
>> > endin
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Thanks for the suggestions Rory, but now that Cabbage is working again
(thanks for your help there too!) I finally got to test this, and it
seems the loop style here is even more dependent on the length of the
note triggering it.  My first theory is that it was due to the printks
in the loop, sometimes console output can really slow things down...
but removing that didn't seem to help.  Here's what I saw with this
new loop style:

If this instr is triggered with:
  event "i", 3, 0, .001
It only counts a few pixels, stopping at 1,0 of any graphic selected
with your new loop.

I have to lengthen that to
  event "i", 3, 0, 1
It reads significantly more, but if I load a large file such as a full
screenshot, it only reads the first row and a few off the second row,
stopping at 11,1.

I know that since this is looping at k-rate, the p3 will factor into
it... but it seems strange to me that these two looping styles produce
such varied results... and I'm also still curious why my original loop
makes *TOO MANY* passes through the loop.  I understand coming up
short if the p3 time isn't long enough, but it seems the logic should
have dictated the loop doesn't continue regardless of p3.

And a second question... is there a better way to do this?  Normally
I'd loop through in i-time to make sure the whole loop completes at
init regardless of the image size, but it appears that imagegetpixel
only outputs at k and a rate, so I don't believe that's an option.
Any suggestions for a better way to handle this are welcome.

On Tue, Dec 29, 2015 at 6:02 AM, Rory Walsh  wrote:
> Yeah. Didn't grasp that properly at all. I'll have another go :) This one
> prints x, 0 to image width, and then increments y? And continues to do so
> until it has printing all Xs for every Y?
>
> instr 3
>   iimage imageload "/home/rory/sourcecode/logo.png"
>   imaxX, imaxY imagesize iimage
>   prints sprintfk("X: %d   Y: %d)\n", imaxX, imaxY)
>
>   kxindex init 0
>   kyindex init 0
>
>   if kyindex     kxindex = (kxindex     if kxindex==0 then
>       kyindex = kyindex+1
>     endif
>     printks sprintfk("counted X:%d Y:%d\n",kxindex,kyindex), 0
>   endif
>
> endin
>
> On 29 December 2015 at 10:30, Kevin Welsh  wrote:
>>
>> Thanks Rory, but I think that either I misunderstand your code or you
>> misunderstand my goal.
>>
>> I need to iterate through X, starting from 0 and going to the maxX for
>> *each separate* row on Y.  During this loop I'm going to be loading
>> these values with imagegetpixel into either a 2d array or some tables
>> (I'm not quite sure the best approach for this yet) to use them as a
>> data source for adsynth.  So basically, when Y is 0, X goes from 0 to
>> maxX reading the row... then increment Y by 1... repeat reading the
>> next row's X values, etc.
>>
>> I could be mistaken, but I don't think your code does this... that
>> said, I could probably work the loop into this style of code easy
>> enough.
>>
>> Thanks for the suggestion.  I'm done csound/cabbage for now, but I'll
>> try some more experimenting with it tomorrow!
>>
>> On Tue, Dec 29, 2015 at 4:20 AM, Rory Walsh  wrote:
>> > I'm not a fan of the goto stuff so I rewrote the instrument to avoid
>> > them(sorry, I should have spent more time looking into why your
>> > instrument
>> > didn't work, but I'm still on holidays ;) Anyhow, it seems to do
>> > everything
>> > I'd expect here?
>> >
>> > ; load image data
>> > instr 3
>> >   iimage imageload "/home/image.png"
>> >   imaxX, imaxY imagesize iimage
>> >   prints sprintfk("X: %d   Y: %d)\n", imaxX, imaxY)
>> >
>> >   kxindex init 0
>> >   kyindex init 0
>> >
>> >   if kyindex> >         kxindex= (kxindex> >         kyindex= (kyindex> >         printks sprintfk("counted X:%d Y%d\n",kxindex,kyindex), 0
>> >   endif
>> > endin
>> >
>> > On 29 December 2015 at 03:09, Kevin Welsh  wrote:
>> >>
>> >> I discovered that if I change what is calling this instrument from:
>> >>     event "i", 3, 0, .01
>> >> to
>> >>     event "i", 3, 0, .001
>> >>
>> >> It loops through the correct number... and even further, if I change it
>> >> to:
>> >>     event "i", 3, 0, .0001
>> >>
>> >> It doesn't go through *ENOUGH* loops.  I guess I need to work out a
>> >> different method to complete the loop.
>> >>
>> >> On Mon, Dec 28, 2015 at 9:45 PM, Kevin Welsh  wrote:
>> >> > Hello everyone.  I'm trying my hand at writing a cabbage instrument
>> >> > similar to Menno's "ImagePlayer" for Blue.  This code is only part of
>> >> > it, this specific instrument only gets called when the filename
>> >> > changes, and is meant to lad the image data into arrays or tables
>> >> > (haven't gotten that far yet, right now it's just counting pixels)
>> >> >
>> >> > When I load a new image, this instrument would send out text of the
>> >> > name to one channel (disname), and text of the X/Y size to another
>> >> > (dispsize).
>> >> >
>> >> > If I load an image, I see the correct size listed in those
>> >> > channels...
>> >> > however after the loops, it reports to my debug channel that it has
>> >> > gone through 13 extra passes on the Y loop.
>> >> >
>> >> > I think the two cggoto lines should be the lines of most interest...
>> >> > the X loop stops correctly where it should, but the Y loop always
>> >> > gives 13 extra... regardless of the size of the image I load.  That's
>> >> > why it now contains "max(0,imaxY-13)", otherwise it should have been
>> >> > handled the same as X.
>> >> >
>> >> > Any idea why this is happening and what I can do to avoid it rather
>> >> > than workaround it?
>> >> >
>> >> > ; load image data
>> >> > instr 3
>> >> >   Sfile chnget "filename"
>> >> >   iimage imageload Sfile
>> >> >   imaxX, imaxY imagesize iimage
>> >> >   chnset sprintfk("text(File: %s)", Sfile), "dispname"
>> >> >   chnset sprintfk("text(X: %d   Y: %d)", imaxX, imaxY), "dispsize"
>> >> >
>> >> >   kxindex init 0
>> >> >   kyindex init 0
>> >> >   loopy:
>> >> >     kxindex = 0
>> >> >   loopx:
>> >> >     kxindex=kxindex+1
>> >> >     cggoto (kxindex> >> >     kyindex=kyindex+1
>> >> >     cggoto (kyindex> >> > chnset sprintfk("text(counted %d %d)",kxindex,kyindex), "debug"
>> >> > endin
>> >>
>> >> Csound mailing list
>> >> Csound@listserv.heanet.ie
>> >> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> >> Send bugs reports to
>> >>         https://github.com/csound/csound/issues
>> >> Discussions of bugs and features can be posted here
>> >
>> >
>> > Csound mailing list Csound@listserv.heanet.ie
>> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> > https://github.com/csound/csound/issues Discussions of bugs and features
>> > can
>> > be posted here
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here