> I put a simple if statement in pix_share_write to replace the
> imageStruct call and it works fine. I think setCSizeByFormat() might
> not be working on the Mac. All those #ifdefs are hard to read! I will
> try to replace it with a single one for __APPLE__ and see if that helps.
i agree that it might be better to just have one big #ifdef _APPLE__
#endif instead of 4 of them
would you change it or should i do it? (and honestly, i much prefer an
#ifdef over an #ifndef for readability)
You can go ahead and do it if you have time now. I may not get to it today.
> This is the tricky part of these objects to deal with. You can either
> allow the user to whatever they want when setting up shm or put in a
> check to help keep them from doing something which might crash or become
> unusable. My original thinking was that anyone using these objects
> would have to really know what they are doing to set them up properly
> and to just let them do it.
i see.
since there were no help-patches, you were the only person who knew
exactly what the objects were doing. when i first tried to use them they
just plain crashed which i found a bit "unusable".
so i was kind of a burnt child and tried to make it nice.
that if pd is meant to be a real programming language then the user must
be able to crash the computer :-)
I should have put up a test patch and some decent comments in the
code. I needed to have the object to spread video capture and
compression between more than one instance of Pd to make it all
'multi-proccessor aware'. I forgot about the objects after that
though.
I have the current one working for up to one 1024x768 RGB buffer.
I'm using it to have pix_snap write to shm and another instance of Pd
record the results as a Quicktime movie. I can get about 30fps
doing this, so the objects are pretty useful.
actually i never really tried to do change the size, but i am not sure
how this would be done (i haven't found a way to resize an already
existing shared memory segment as long as processes are attached to it)
so we might have to notify all related objects that they should detach
themselves (which i don't know how to do)
remember that the given size is just the amount of memory reserved.
you can send images of any size via this segment, as long as the data
fits into the reserved memory.
so i am not sure whether there is a realy need for resizing on the fly.
one possibility that comes to my mind is, that we could use 2 portions
of shared memory: one fixed-sized segment which just holds the key to
the actual data segment (and probably all the meta-data such as
dimensions,...)
however, i am not sure whether this all would work with multiple
[pix_share_write]s accessing the same memory (which i think is a nice
feature, though i don't have an application at hand)
My thinking on the resizing is if the objects are 'smart' enough then
you could just put them into a render chain and any image that they get
feeds them. I recall that Chris K and I got a little bit of this
going for vDSP/jMax, but that was a while ago. I think our
purpose was just one shm region that set aside a large enough size for
any video the user was likely to throw at it. I believe the first N
bytes were set aside for the x, y and c size to let the receiver know
how much of the region to copy out and the dimensions to pass to the
rest of the processes.
Would this be a viable system?
- only one pix_share_write per ID (probably has to be like this anyway)
- default max size is a reasonable size (1024x768, 1280x1024,???)
- arguments to the object can set the max size
- any image that comes in under the max size set the x,y,c and copy the frame into the shm buffer
- an image over max size would throw a message with a hint to manually set the max
- some sort of flag or counter to determine when images are sent by _write so _read doesn't copy out bad data
This is kind of like sub texturing using 2D textures in a way. It
could free end users from having to set anythign beyond the ID for
common video sizes (320x240, 640x480). It is potentially wasteful
if the default is a lot bigger than the images used and it looks like
OSX by default is limited to 4MB of total shm, but manually setting the
max would help avoid this.
Is this crazy talk?
hmm. one of my ideas was to export the shared-memory thing into a
different set of objects (not related to Gem!)
then a pointer to this memory would be passed to the read/write objects.
this way they would not need to know anything about shared memory and it
would allow for the biggest flexibility.
Like a Jack/Rewire method of passing video between apps?
cgc