Hi developers,
is there a reason why the output of the currentFrame outlet_float(m_outNumFrames,m_currentFrame); (which is always 0 by the assignment immediately above it) is commented out in
pix_record :: stopRecording()
in pix_record.cpp??
I have found that using this output, if I uncomment it, I can avoid problems with pix_record trying to record things while it is still writing out the file. I think this is the problem I have been having with PD crashing.
Cheers, Tim
I uncommented it which is the correct behavior compared to the original recordQT object.
On 10/3/07, Tim Boykett tim@timesup.org wrote:
Hi developers,
is there a reason why the output of the currentFrame outlet_float(m_outNumFrames,m_currentFrame); (which is always 0 by the assignment immediately above it) is commented out in
pix_record :: stopRecording()in pix_record.cpp??
I have found that using this output, if I uncomment it, I can avoid problems with pix_record trying to record things while it is still writing out the file. I think this is the problem I have been having with PD crashing.
Cheers, Tim
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
chris clepper wrote:
I uncommented it which is the correct behavior compared to the original recordQT object.
i don't know why it has been removed. however, why don't we just use a separate outlet (or a different message) to indicate the end of recording? i am not a very big fan of ambigous messages...
mfgas.dr IOhannes
btw: chris, could you please commit the rest of the min/max changes?
On 04/10/2007, at 5:37 PM, IOhannes m zmoelnig wrote:
chris clepper wrote:
I uncommented it which is the correct behavior compared to the original recordQT object.
i don't know why it has been removed. however, why don't we just use a separate outlet (or a different message) to indicate the end of recording? i am not a very big fan of ambigous messages...
I do not think that the frameNumber 0 is an ambiguous message in this case.
However I think that an output telling us the state of the object might be useful. But perhaps it is just an over-featuring.
chrz, tim
hi list, just a question about sys_vgui() ...
i'm trying to get some info about a widget on the pd canvas, but sys_vgui() is declared to retun void ... so i cannot get anything using this function ...
there is another way to run tcl/tk scripts in the pd canvas and get the returned data of this scripts?
thanks, ll.
On Sun, 31 Oct 2004, Rory Walsh wrote:
Can anyone explain what exactly this routine does? When trying to write an object to display a bitmap or jpeg on the PD canvas I came across this very useful routine. I guess it’s a routine that interpreters tcl/tk scripts? Can anyone explain what exactly is does and what the parameters are? Cheers,
Pd is a client-server system connected by a socket. the client sends to the server using the "pd" proc in Tcl, in the same format as [netsend]. The server sends to the client Tcl commands using sys_gui(), and the client calls "eval" on them.
sys_gui() takes a single string argument. sys_vgui() is a combination of sprintf() with sys_gui(), so it takes the same arguments as printf(), which are (const char *format, ...) where format is a %-string.
Lluis Gómez i Bigordà wrote:
hi list, just a question about sys_vgui() ...
i'm trying to get some info about a widget on the pd canvas, but sys_vgui() is declared to retun void ... so i cannot get anything using this function ...
there is another way to run tcl/tk scripts in the pd canvas and get the returned data of this scripts?
the way to do this is via a callback function: with sys_vgui you call a function in the pd-gui process, which then can send back a message to a pd; you have to bind your object to a special receiver to receive this message.
you will also be able to receive this message via a [r <special receiver>] object, there is no way to do an exclusive communication.
fmasd.r IOhannes
On Oct 15, 2007, at 10:30 AM, IOhannes m zmoelnig wrote:
Lluis Gómez i Bigordà wrote:
hi list, just a question about sys_vgui() ...
i'm trying to get some info about a widget on the pd canvas, but sys_vgui() is declared to retun void ... so i cannot get anything using this function ...
there is another way to run tcl/tk scripts in the pd canvas and get the returned data of this scripts?
the way to do this is via a callback function: with sys_vgui you call a function in the pd-gui process, which then can send back a message to a pd; you have to bind your object to a special receiver to receive this message.
you will also be able to receive this message via a [r <special receiver>] object, there is no way to do an exclusive communication.
Does anyone know of a simple, clean example of this in action? I was looking for something similar in the past.
.hc
------------------------------------------------------------------------ ----
All information should be free. - the hacker ethic
-
chris clepper -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Lluis Gómez i Bigordà -
Tim Boykett