Re: [PD] "waking up" an audio patchbay abstraction upon live creation.

Thanks IOhannes. For me, the dynamic patch option (included in the demo link I sent) is probably the best workaround, since it passes audio instantly upon creation as expected. Since I'm usually holding a guitar as I perform, it's fewer keystrokes and stuff I'll need to worry about. I'd rather

Re: [PD] "waking up" an audio patchbay abstraction upon live creation.

On 12/17/2017 06:40 PM, Brady Sharp wrote: > [...] this is kind of known (at least to me :-)). my workaround for live coding sessions is simply to hit Ctrl-S (save the patch), which will force a recompilation of the DSP graph as well. that workaround is so simple and effective, that i didn't

[PD] [PD-announce] 2x Associate Professorships: Music Technology & Popular Music (University of Oslo)

Dear all, We are happy to announce two new (tenured) associate professorships at the University of Oslo: *Associate Professor in Music Technology ** *The successful candidate will play an

[PD] "waking up" an audio patchbay abstraction upon live creation.

I'm working on an audio patchbay function, with a small abstraction that simply [receive~]'s from one bus and [throw~]'s to another. I'm using $1 and $2 in the bus names, but that doesn't seem to be the issue, as it does the same for fixed-name buses as well. What happens is that when I create

Re: [PD] pix_film performances question

I have a recent Gem version. With the same video loaded with 12 [pix_film], the CPU go from 1% to 5%. First, it increase to 65% and goes down to 5%. ++ Jack Le 17/12/2017 à 16:56, Nicola Pandini a écrit : > woops, forget that, sorry :-) > > I'm using a Debian Stretch with puredata 0.47.1 and

Re: [PD] pix_film performances question

Oh, good news, thanks. I'll try to compile and test that. Il 17/12/2017 14:30, Antoine Rousseau ha scritto: Hi, this should be fixed in next release, with: https://github.com/umlaeute/Gem/pull/138 "change sleep time of pix_film's grabThread() from 100us to 5ms" Antoine Rousseau

Re: [PD] pix_film performances question

woops, forget that, sorry :-) I'm using a Debian Stretch with puredata 0.47.1 and Gem 0.93.3 To test that, you can simply create 10-15 pix_film objects, and load the same video to every pix_film. If you just do that, you'll see the cpu usage going up. Il 17/12/2017 11:36, Jack ha scritto:

Re: [PD] Review of expr 0.55 (released in 0.48) and a Pull Request

> Yes, if it is not too late with Miller, I will fix the fexpr float to signal matter and > add avg() and Avg() before the year is over. Great, I have a new Pull Request now, for an update to the help file of expr, but this is mostly aesthetical as it now aligns to the new font size from 0.48-1

Re: [PD] IP address of local machine

In Unix, all is a file, did you try to look inside the /proc/net directory to find your local IP ? Then, [text] can be used to load a specific file. ++ Jack Le 17/12/2017 à 14:59, Roman Haefeli a écrit : > On Son, 2017-12-17 at 10:48 +, Andy Farnell wrote: > >> If the server is brokering

Re: [PD] IP address of local machine

On Son, 2017-12-17 at 01:41 +0100, Roman Haefeli wrote: > > If there's no easy way, I might turn that into a feature request for > iemnet's [udpclient] and [tcpclient] to print the src IP address and > src port on the status outlet. Does that make sense? Here it is:

Re: [PD] IP address of local machine

On Son, 2017-12-17 at 10:48 +, Andy Farnell wrote: > If the server is brokering the traffic then you never need to know  > the private network addresses as NAT will map them to public port > numbers and the router will map the returned packets back to local > addresses. > > But I guess you

Re: [PD] pix_film performances question

Hi, this should be fixed in next release, with: https://github.com/umlaeute/Gem/pull/138 "change sleep time of pix_film's grabThread() from 100us to 5ms" Antoine Rousseau http://www.metalu.net __ http://www.metaluachahuter.com/

Re: [PD] IP address of local machine

Hi Roman, If the server is brokering the traffic then you never need to know the private network addresses as NAT will map them to public port numbers and the router will map the returned packets back to local addresses. But I guess you want to use the server to do peer discovery and then

Re: [PD] pix_film performances question

Hello, Do you have a simple patch ? Which OS, Pd and Gem version ? ++ Jack Le 17/12/2017 à 11:16, Nicola Pandini a écrit : > Hi list, > > I've a problem with a patch with a lot of pix_film objects. > > I noticed that pix_film starts consuming cpu when it loads a video, and > it never reduce

Re: [PD] IP address of local machine

Le 17/12/2017 à 01:41, Roman Haefeli a écrit : > > On Sam, 2017-12-16 at 21:26 +0100, Jack wrote: >> Your router has a public and local IP. So, i guess your local machine >> has only a local IP. Then, your local machine need to pass through >> your >> router to access remote server. Your router

[PD] problems testing MIDI clock input

I remember some time ago complaining about the jitter in Pd's output timing and someone, maybe Miller, indicated a change I could do to the source to improve the timing, I'm guessing it wasn't something that ever got merged into the source. I forget what it was though. Hi, you can reduce the

[PD] pix_film performances question

Hi list, I've a problem with a patch with a lot of pix_film objects. I noticed that pix_film starts consuming cpu when it loads a video, and it never reduce the consuming, even when playback is stopped, or when its gemhead is disabled. Is it a bug? Are there any workarounds? -- Nicola