Hi,
I may have been sensitive, I needed 2 days break, sorry. If we focus on the
important facts, I received really constructive feedbacks and I've been
able to improve the library for the next release.
Joao suggestions :
- The properties window will have a fixed size.
- We can set (in the code)
i very much doubt miller will include stuff in vanilla that's not backwards
compatible. seeing as how these objects don't even work with my
(relatively) recent 0.42.5 version, i can't see how they'd pass.
On Mon, Jan 13, 2014 at 6:00 PM, Pierre Guillot guillotpier...@gmail.comwrote:
Hi,
I
Well, backwards compatibility can have reasonable limitations and perhaps this
is one.
On Jan 13, 2014, at 6:18 AM, i go bananas hard@gmail.com wrote:
i very much doubt miller will include stuff in vanilla that's not backwards
compatible. seeing as how these objects don't even work with
As Hans has proposed for years, IMO this is really the only way to perhaps
solve the PD gui development doesn't move fast enough problem in the long
term. In this case, Miller would have the core (in libpd) the pd-vanilla
wrapper gui formally separated while everyone else can then use the same
Hi Filippo,
You're welcome.
You probably forgot to reply-to-all, but I added pd-list to the
conversation. I hope you don't mind, but I do this ...
a) to prevent ten people to answer the same question, not knowing that nine
others are or have been spending time to do exactly the same, and
b) for
is it possible/feasible to add a switch so that "old" objects don't get replaced by the new ones? e.g. by analysing the parameters of the creation objects? if so, and someone delivers the code for this (I don't know how to do it myself), there might be a better chance of these objects making it
I'm not super-familiar with the guts of Pd's scheduling system, but I think
that if one metro object outputs a bang to separate tabplay~ objects, both
should start playing at exactly the same time.
While using line~ or phasor~ can lead to more robust samplers (allowing you
to adjust playback
On 01/13/2014 09:32 AM, Dan Wilcox wrote:
As Hans has proposed for years, IMO this is really the only way to
perhaps solve the PD gui development doesn't move fast enough
problem in the long term. In this case, Miller would have the core (in
libpd) the pd-vanilla wrapper gui formally
Hi,
is there a way to get information on whether Pd has been started with
-batch or -nogui from inside a patch?
I am trying to make unit tests by starting a Pd instance in batch mode
from Python, and comparing the output from [stdout] to the desired
result, and I want Pd to close itself via [;
Thank you Funs for pointing the reply-all thing out, sorry! Now sending to the
whole list :)
I'd be happy to keep tabplay for this since it seems solid and easy to work
with, but will have to look deeper into the phasor~ solution, it looks very
interesting.
Brian, thanks for your suggestions,
Woops, forgot the reply-all.
On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes jancs...@yahoo.com wrote:
On 01/13/2014 09:32 AM, Dan Wilcox wrote:
As Hans has proposed for years, IMO this is really the only way to perhaps
solve the PD gui development doesn't move fast enough problem in the long
hello,
the most simple solution is to add a message at startup :
pd -batch -send testquit bang
[loadbang]
|
[message for object(
|
[object-to-test]
|
[t b a]
| |
| [stdout]
|
| [r testquit]
| |
| [1
| |
[spigot 0]
|
[; pd quit(
cheers
c
Le 13/01/2014 20:26,
On Mon, 2014-01-13 at 20:26 +0100, Thomas Mayer wrote:
Hi,
is there a way to get information on whether Pd has been started with
-batch or -nogui from inside a patch?
Though I consider Cyrille's approach the clean way for your specific
purpose, there is also a way to check for '-batch'
On 01/13/2014 03:11 PM, Dan Wilcox wrote:
Woops, forgot the reply-all.
On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes jancs...@yahoo.com
mailto:jancs...@yahoo.com wrote:
On 01/13/2014 09:32 AM, Dan Wilcox wrote:
As Hans has proposed for years, IMO this is really the only way to
perhaps solve
On Jan 13, 2014, at 5:05 PM, Jonathan Wilkes jancs...@yahoo.com wrote:
On 01/13/2014 03:11 PM, Dan Wilcox wrote:
Woops, forgot the reply-all.
On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes jancs...@yahoo.com wrote:
Sorry, I don't know quite what you're referring to here. The only two
Hi list,
I'm sending data between two computers, in every 10ms. For fast networking,
TCP is better result? I don't know which is better. Most tutorials show
example of OSC with UDP. Why?
Thanks,
Jong
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and
Ah wait, duh. Of course the graph needs to know positioning, that's how it
determines execution order or independent blocks of objects right?
On Jan 13, 2014, at 5:14 PM, Dan Wilcox danomat...@gmail.com wrote:
Does the dsp graph rely on positioning? I thought only via connections. I'd
hi, i'm not an expert on PD but my feeling was that TCP does error checking
while UDP does not, and that at least is one reason why TCP should be
slower than UDP in a typical networking situation.
scott
On Mon, Jan 13, 2014 at 2:20 PM, Jonghyun Kim agitato...@gmail.com wrote:
Hi list,
I'm
Hi,
On 13.01.2014 21:20, Cyrille Henry wrote:
hello,
the most simple solution is to add a message at startup :
pd -batch -send testquit bang
thanks, that worked liked a charm. Minor correction though: The command
line is
pd -batch -send testquit bang
[loadbang]
|
[message for object(
On 01/13/2014 05:14 PM, Dan Wilcox wrote:
On Jan 13, 2014, at 5:05 PM, Jonathan Wilkes jancs...@yahoo.com
mailto:jancs...@yahoo.com wrote:
On 01/13/2014 03:11 PM, Dan Wilcox wrote:
Woops, forgot the reply-all.
On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes jancs...@yahoo.com
Pretty much. TCP ensures that every packet gets there intact. You have
a back and forth between the server of the packet and the client to
make sure. UDP just sends the packet where you ask, and doesn't
confirm whether it makes it at all. Generally for most OSC use the
number of packets you're
21 matches
Mail list logo
