• hallo hallo!

    I am starting a new patch where I want to trigger pictures with midi signals.
    I am using a 800 * 600px stage, and I am importing a 75 * 75px image. I tried it with jpg, bmp and psd files, and what happens is that it is automatically resized to fill the whole stage. In this case the image that has a size of 75 * 75px, appears to be 600 * 600px. 
    question 1 - Is there a way to prevent this automatical resize?
    I tried to scale them down again, but the result is not very nice. it distorts the image in a not-very-nice way. I used "zoomer", "scaler" and "panspinzoom".
    Also, the image is a white figure with black background, but when imported, I see a diffused white border that doesnt belong to the file.
    question 2 - How to prevent this white border?
    I attach an image so you can see.


  • Izzy Guru


    The first thing that comes up to my mind to help you, is open your picture editor software of choice, create a new canvas of 800x600 and paste the 75x75 image into it, this prevents the unwanted resizing.


  • ey michel.

    It won´t work as I expect, since what I actually want to do is to generate a mosaic with the images, having 8 images high * 8 images with, that they could appear either individually or simultaneously in the screen.
    If I do what you suggest, I wouldnt be able to see more that one image at the time.
    I attach a simple example of what I mean, having 64 images in the screen, being each one of them triggered by a midi signal. do I explain myself?
    pd. regarding the white frame, making this mosaic in photoshop I realized that the white frame might be already in the image, and it is not an isadora failure. I will be checking this.-


  • confirmed: white border was in the picture file

  • How about having every picture player connected to a projector with the width and height set so as to show the picture at its native resolution.

    I'm not sure if there is any resampling going on but it looks ok to my eye.
    If you are using the 2.0 beta you could use the Texture Picture Player which presumably loads the image into GPU at native resolution.
    Hmm I linked to a picture on my dropbox there but it came up as a broken link - why? - here it is attached anyway.


  • I will check what you say, but if I understand correctly, this solution proposes to have 64 projectors? isnt this too much for the performance of the project?

  • Umm. Don't Know! Sorry!

  • have you tried the Sprite actor?

  • I will and come back with an update

  • this is one way to do it: make a string of 64 Sprites, each one feeding into the background of the next, each one with a picture player feeding into the 'sprite' input (via a Video Fader - if necessary)

    each Sprite actor has its horiz and vert controls set to make it a specific point on the grid. your MIDI watchers control the picture number of each Picture Player or the 'visible' input on each Sprite. it will take a while to make. i'm sure a bunch of Macros would be the way to go....

  • before going forward, 2 things:

    gaspav. I see in your image that your picture player is sending a "vid-cpu" string. I havent found the way to do the same. what am I missing?
    Also, I dont see a "Texture Picture Player" actor in my v2.0.0b4

  • Are you an earlier adopter? Dunno if that makes any difference.

    But I have two actors - Picture Player and Texture Picture Player - one puts out vid-cpu, the other vid-gpu. The first is connected to a normal projector, the second to a Texture Projector.
    Be interested to know if 64 projectors has an impact on performance though! Maybe I should try it. All that clicking though.

  • I will open this new question in a new post. and in the meantime I will try out what I already have in hands

  • Izzy Guru


    You will only see the new actors and all the new features if you have purchased the 2.0 update.


  • @dbini

    I am using the mechanism you explained, and I am enjoying the results a lot!

  • I made a patch with 100 picture players and projectors to see what would happen.

    I'm not sure what did happen!
    My patch runs at 30fps most of the time but then sometimes it seems to dip out and drop much lower - if I move the cursor around for example.
    Anyway it might work out for you?
    Edit - Yeah sorry @dbini your solution is a million times better!


  • @gavspav - same here. it runs ok (25fps) and sometimes goes dramatically lower than that (13fps)

    I already sorted out the patch with the sprite actor, as suggested by @dbini, and it works very nice although the performance is also not excellent sometimes since I am triggering the images by midi, so   now I am simply waiting for the famous "texture picture player" to check out how the performance improves.

  • Well you could always make a bunch of one frame movies whilst you wait ;-)