[PD-dev] Fwd: SourceForge Project Upgrade

2013-06-04 Thread IOhannes m zmoelnig
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

so while we were busy making a lazy consensus on how to deal with the
sf upgrade plans, sourceforge has upgraded the repositories for us.

afaik, this changes all the links to checkout/update (SVN)  and
clone/pull (GIT).

someone might want to update all the information in the wikis.

fgmasdr
IOhannes




-  Original Message 
Your svn repository in upgraded project pure-data is now ready for use.

Old repository url:
http://pure-data.svn.sourceforge.net/svnroot/pure-data

New repository checkout command: svn checkout --username=zmoelnig
svn+ssh://zmoel...@svn.code.sf.net/p/pure-data/svn/ pure-data-svn

You should do a checkout using the new repository location.  The old
repository is read-only now.

For more detailed instructions on migrating to your new repo, please
see
https://sourceforge.net/p/forge/community-docs/Repository%20Upgrade%20FAQ/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlGtkGoACgkQkX2Xpv6ydvRm9QCfS+6r184K5To9V/Qv20Dxp3Fm
pBEAniCBgZJcABcpwfopfRmocDSGwAp6
=JxvM
-END PGP SIGNATURE-

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] Fwd: SourceForge Project Upgrade

2013-06-04 Thread IOhannes m zmölnig

On 06/04/13 08:59, IOhannes m zmoelnig wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

so while we were busy making a lazy consensus on how to deal with the
sf upgrade plans, sourceforge has upgraded the repositories for us.

afaik, this changes all the links to checkout/update (SVN)  and
clone/pull (GIT).



in practice this means, that all developers should relocate their 
repository URLs (that is: tell their local checkout  of the new location).


this is how i did it, and it was rather painless:
$ cd ~/src/svn/pure-data/
$ svn relocate https://svn.code.sf.net/p/pure-data/svn/trunk/


gfmsdr
IOhannes

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] jack dbus?

2013-06-04 Thread katja
On Tue, Jun 4, 2013 at 3:08 AM, Jonathan Wilkes jancs...@yahoo.com wrote:

[...]

 Sorry, I'm talking about a few things at once.  One would be to test Pd by
 itself
 with ALSA backend vs. Pd by itself with JACK backend.  That would provide
 some data re: the page you linked to about latency.  (My suggestion about
 Pd-JACK + VLC-with-jack-backend-JACK was meant to cover that case
 and also compare to Pd-JACK +Pulse-JACK, but as you say we can delve
 into that later.)

 The other is: what's a recommendable setup for using Pd in GNU/Linux
 with acceptable/controllable latency while still behaving with the rest of
 the
 system.  Your Pd/Pulse/JACK measurements help to address that.

You're right, JACK's latency 'discrepancy' should be investigated
separately. On my system I observe this behaviour:

- Pd with ALSA: measured latency is [Pd-nominal-latency + 3] milliseconds
- Pd through JACK with ALSA: measured latency is [JACK-nominal-latency
* 2 + 3] ms
- Pd + PulseAudio through JACK with ALSA: [JACK-nominal-latency * 2 + 3] ms

Here it seems that JACK's latency is double it's buffer size, no
matter if PulseAudio is connected or not. But wait, it's logical! The
loopback signal goes through JACK twice. Buffering is applied at
capture and at playback, and by default both buffers have size [frames
* periods]. Check with command jack_lsp -l. Optionally, extra input
and/or output latency can be added, however this does not reflect in
my measurements.

Apart from the effect that JACK's latency may be different from what
you'd expect, there is the effect that Pd + internet video requires
more buffering than Pd only. It's a pity that JACK's bufsize can not
be set in runtime.

It seems reasonable to expect and accept increased latency if you want
to play internet video's etc. together with Pd. Switching between
setups would be scriptable to make it easier (also see
http://gareus.org/wiki/qjackctl_dbus). But for the moment, I even get
stuck many times when switching 'by hand'. Apparently, the order of
operations is very critical. If it goes wrong, getting the d-bus error
from JACK I haven't found another option than kill the jackdbus
process and try again.


Katja

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev