I'm using the [pd~] object to run a Gem window in a subprocess. I've noticed that the Gem window won't start rendering until I turn dsp on in both processes.
Is there any way to run Gem in a [pd~] subprocess without turning on dsp?
Thanks
Antonio
On 08/05/13 07:20, Antonio Roberts wrote:
I'm using the [pd~] object to run a Gem window in a subprocess. I've noticed that the Gem window won't start rendering until I turn dsp on in both processes.
Is there any way to run Gem in a [pd~] subprocess without turning on dsp?
you probably do not want to be using pd~ for this, it is designed for working with DSP.
For a separate thread for Gem you don't want that overhead, you just need a new instance of pd ... communicate between them with sockets.
Simon
Am 08.05.2013 um 03:56 schrieb Simon Wise simonzwise@gmail.com:
On 08/05/13 07:20, Antonio Roberts wrote:
I'm using the [pd~] object to run a Gem window in a subprocess. I've noticed that the Gem window won't start rendering until I turn dsp on in both processes.
Is there any way to run Gem in a [pd~] subprocess without turning on dsp?
you probably do not want to be using pd~ for this, it is designed for working with DSP.
For a separate thread for Gem you don't want that overhead, you just need a new instance of pd ... communicate between them with sockets.
I disagree. For some uses it can be very practical to use pd~ to separate audio and video. And it has advantages, like not having to care about ports being still blocked from a previous crash and other things. In order to make the pd~ process work without dsp you still need to do a loadbang [pd dsp 1(, but then you may switch dsp off again after a second or so. this technique works well.
m.
Le 08/05/2013 09:02, Max a écrit :
Am 08.05.2013 um 03:56 schrieb Simon Wise simonzwise@gmail.com:
On 08/05/13 07:20, Antonio Roberts wrote:
I'm using the [pd~] object to run a Gem window in a subprocess. I've noticed that the Gem window won't start rendering until I turn dsp on in both processes.
Is there any way to run Gem in a [pd~] subprocess without turning on dsp?
you probably do not want to be using pd~ for this, it is designed for working with DSP.
For a separate thread for Gem you don't want that overhead, you just need a new instance of pd ... communicate between them with sockets.
I disagree. For some uses it can be very practical to use pd~ to separate audio and video. And it has advantages, like not having to care about ports being still blocked from a previous crash and other things. In order to make the pd~ process work without dsp you still need to do a loadbang [pd dsp 1(, but then you may switch dsp off again after a second or so. this technique works well.
yes, but pd~ will still be clocked by pd at audio signal rate. so if pd~ can't render the Gem windows as fast as it should, then it will block the pd audio signal.
so, it did not really separate audio and video.
cheers c
m.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
In order to make the pd~ process work without dsp you still need to do a loadbang [pd dsp 1(, but then you may switch dsp off again after a second or so. this technique works well.
I've tried this, and it's an improvement but it still causes clipping in the audio.
Essentially, what I'm trying to do is a screen recording of myself using a patch. Nearly all screen recording software for Linux use Alsa so I'm unable to record audio, due to PD locking Alsa when it's running. So, I instead am using Jack and this script http://pastebin.ca/2373980
However, even by separating the audio and video using [pd~] I'm still getting clipping in the audio
On 8 May 2013 08:02, Max abonnements@revolwear.com wrote:
Am 08.05.2013 um 03:56 schrieb Simon Wise simonzwise@gmail.com:
On 08/05/13 07:20, Antonio Roberts wrote:
I'm using the [pd~] object to run a Gem window in a subprocess. I've noticed that the Gem window won't start rendering until I turn dsp on in both processes.
Is there any way to run Gem in a [pd~] subprocess without turning on dsp?
you probably do not want to be using pd~ for this, it is designed for working with DSP.
For a separate thread for Gem you don't want that overhead, you just need a new instance of pd ... communicate between them with sockets.
I disagree. For some uses it can be very practical to use pd~ to separate audio and video. And it has advantages, like not having to care about ports being still blocked from a previous crash and other things. In order to make the pd~ process work without dsp you still need to do a loadbang [pd dsp 1(, but then you may switch dsp off again after a second or so. this technique works well.
m.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
This discussion makes me wonder, how hard would it be to reimplement Gem in a separate thread to avoid all these ugly workarounds just like pidip (or was that pdp?) has an option of running in a separate thread?
Am 08.05.2013 um 12:14 schrieb Antonio Roberts antonio@hellocatfood.com:
In order to make the pd~ process work without dsp you still need to do a loadbang [pd dsp 1(, but then you may switch dsp off again after a second or so. this technique works well.
I've tried this, and it's an improvement but it still causes clipping in the audio.
Essentially, what I'm trying to do is a screen recording of myself using a patch. Nearly all screen recording software for Linux use Alsa so I'm unable to record audio, due to PD locking Alsa when it's running. So, I instead am using Jack and this script http://pastebin.ca/2373980
However, even by separating the audio and video using [pd~] I'm still getting clipping in the audio
i think in your scenario you should record from within Pd, e.g. using writesf~ then even if you hear clips while you are recording they will not be in the recording.
m.
i think in your scenario you should record from within Pd, e.g. using writesf~ then even if you hear clips while you are recording they will not be in the recording.
m.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Sorry, premature send.
Are you sure this is always the case? I've had terrible sync issues between video and sound, due to audio hiccups while recording.
J
On May 9, 2013, at 1:42 PM, J jaime.oliver2@gmail.com wrote:
i think in your scenario you should record from within Pd, e.g. using writesf~ then even if you hear clips while you are recording they will not be in the recording.
m.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You are right, it doesn't solve the a/v synchronization issues, just removes the glitches in the Audio. Basically you can choose if you want to have clicks in the audio or desynchronized video. Or you use something like a epiphan grabber device.
m.
Am 09.05.2013 um 20:46 schrieb J jaime.oliver2@gmail.com:
Sorry, premature send.
Are you sure this is always the case? I've had terrible sync issues between video and sound, due to audio hiccups while recording.
J
On May 9, 2013, at 1:42 PM, J jaime.oliver2@gmail.com wrote:
i think in your scenario you should record from within Pd, e.g. using writesf~ then even if you hear clips while you are recording they will not be in the recording.
m.
i think in your scenario you should record from within Pd, e.g. using writesf~ then even if you hear clips while you are recording they will not be in the recording.
I understand that this will record the audio, but how would I then synchronise this with the video without resorting to guesswork?
Antonio
On 9 May 2013 10:15, Max abonnements@revolwear.com wrote:
Am 08.05.2013 um 12:14 schrieb Antonio Roberts antonio@hellocatfood.com:
In order to make the pd~ process work without dsp you still need to do a loadbang [pd dsp 1(, but then you may switch dsp off again after a second or so. this technique works well.
I've tried this, and it's an improvement but it still causes clipping in the audio.
Essentially, what I'm trying to do is a screen recording of myself using a patch. Nearly all screen recording software for Linux use Alsa so I'm unable to record audio, due to PD locking Alsa when it's running. So, I instead am using Jack and this script http://pastebin.ca/2373980
However, even by separating the audio and video using [pd~] I'm still getting clipping in the audio
i think in your scenario you should record from within Pd, e.g. using writesf~ then even if you hear clips while you are recording they will not be in the recording.
m.
Hm. Perhaps you could use the CPU load to freeze video when it goes above 100%. Use the IEM version, which is more responsive than the built-in load meter.
An alternative would be to record an extra audio track using writesf~ with some synchronization data as audio, a bit like SMPTE used to work. Then at least you could framesync the audio in an NLE, somehow to track the frame you are recording via audio pulses of different frequencies - some signal derived from the frame number.
This is a problem I have faced many times, and although I tend to use two instances of Pd communicating with one another using netsend/netreceive, it's the same issue.
I haven't tried it yet, but I believe there is an external or something called "framesync"
Ed Ninja Jamm - a revolutionary new musix remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
----- Original Message -----
From: Antonio Roberts antonio@hellocatfood.com To: Max abonnements@revolwear.com Cc: PD list pd-list@iem.at Sent: Thursday, 9 May 2013, 21:16 Subject: Re: [PD] Render a Gem window in [pd~] without dsp turned on
i think in your scenario you should record from within Pd, e.g. using
writesf~ then even if you hear clips while you are recording they will not be in the recording. I understand that this will record the audio, but how would I then synchronise this with the video without resorting to guesswork?
Antonio
On 9 May 2013 10:15, Max abonnements@revolwear.com wrote:
Am 08.05.2013 um 12:14 schrieb Antonio Roberts
In order to make the pd~ process work without dsp you still need to
do a loadbang [pd dsp 1(, but then you may switch dsp off again after a second or so.
this technique works well.
I've tried this, and it's an improvement but it still causes
clipping
in the audio.
Essentially, what I'm trying to do is a screen recording of myself using a patch. Nearly all screen recording software for Linux use Alsa so I'm unable to record audio, due to PD locking Alsa when it's running. So, I instead am using Jack and this script http://pastebin.ca/2373980
However, even by separating the audio and video using [pd~] I'm
still
getting clipping in the audio
i think in your scenario you should record from within Pd, e.g. using
writesf~ then even if you hear clips while you are recording they will not be in the recording.
m.
--
antonio@hellocatfood.com http://www.hellocatfood.com ============================
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 05/10/2013 12:44, Ed Kelly wrote:
Hm. Perhaps you could use the CPU load to freeze video when it goes above 100%. Use the IEM version, which is more responsive than the built-in load meter.
ain't the iem version just a wrapper around the "built-in load meter"? (there is no built-in load meter, but Pd ships with a patch that uses [cputime] to implement a load meter, very much like the [dsp] object of iemlib). my point is, that is is quite simple to change the responsiveness of any of these load meters, and there's no need to stick with the defaults if you don't like them.
fgsmdf IOhannes
-
Antonio Roberts -
Cyrille Henry -
Ed Kelly -
IOhannes m zmölnig -
Ivica Ico Bukvic -
J -
Max -
Simon Wise