Dear LAD,
In studying complex network (a doctorate research),
I got into interaction networks because of its utility for understanding
social systems.
This lead me to GMANE database:
gmane.org
in which LAD, LAU, LAA (i think), and about 20 thousand other lists
are hosted as public and with data available via RSS.
After experimentations with some lists, in writing results in an article format,
I chose 4 lists: the GNU C++ stdlib development list (official
perhaps), LAU, LAD and Metareciclagem, a gadget-media-activist list
from Brazil.
This article was sent to arXiv:
arxiv.org/abs/1310.7769
and is currently being revised by authors, with latest version here:
http://sourceforge.net/p/labmacambira/fimDoMundo/ci/master/tree/textos/evol…
Some visualizations of these networks in evolution are in:
http://www.youtube.com/watch?v=-t5jxQ8cKxM&list=PLf_EtaMqu3jU-1j4jiIUiyMqyV…
and:
http://hera.ethymos.com.br:1080/redes/python/autoRede/escolheRedes.php
Among all options available for doing this research, I chose LAD and
LAU with esteem. This lists were quite helpful to me in many
occasions, specially in the period 2005-2009. Anyway, this raises a
question about this kind of analysis, if it is desirable, invasive in
public lists/data. As they are publicly accessible, users should have
access also to what kind of information one is able to extract from
such data? Or should it be restricted to enterprises, government
parties and individuals not sharing about it? I number participants,
so names don't appear on results and even in the process of data
mining, but should that be? Should that hold for public data?
Of course, this discussion might make sense only when there are no
aggressive intents, such as developing interfaces to expose someone,
which is probably not cool in any case.
Cheers!
//r
--
GNU/Linux User #479299
labmacambira.sf.net
On ven. 20/09/13 13:11 , Harry van Haaren <harryhaaren(a)gmail.com> wrote:
> Hello all Users & Devs of linux-audio-land,
>
> Moving forward from the topic on Aeolus and forking projects, perhaps it is
> wise to look at how the community as a whole can grow from this situation:
>
> 1) It seems the frustration of forks is mainly due to lack of
> communication.
> 2) Had appropriate communication been in place, patches could have been
> merged.
> 3) If 1) and 2), then the community flourishes as a whole.
>
> In the Aeolus thread on LAD, Michel Dominique wrote (and I feel its
> relevant here):
> "That imply we must communicate more with each other"
> "I think this is a big problem, and not only related to Fons work, or the
> LAD, but to the whole community."
One think I have done is to add in the About box a few buttons to launch
things like the mail list subscription page, mailto and irc.
The function look for $BROWSER, if it doesn't exist, the user get the
opportunity to set it, and the browser will do the rest.
It is too early now for me to know if it make a big difference. This will not
replace an email list, but can be a good complement, and make life
easier for someone that want to get in touch with the development, or
have an issue, a comment or whatever to ask or report.
And well, this is oriented first to users. Developers must be able to find
my email on the website or the source code...
>
> The mailing list you're reading from now is one of the central hubs for the
> community:
> The -developers list is the perfect place to announce projects, forks,
> patches etc.
+1
> The -users list is good for asking users and interested parties questions.
+1
Dominique
>
> I will try to announce more patches / code, to contribute upstream, and
> hopefully benefit the community.
> Cheers, -Harry
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev [1]
>
>
>
> Links:
> ------
> [1]
> http://awebmail.vtx.ch/parse.php?redirect=http://lists.linuxaudio.org/listi
> nfo/linux-audio-dev
>
Hey !
I've toyed a bit with loop, it's great and all, but -except if I missed
the feature- I haven't found any ways to disable sync'ed record and,
more importantly, sync'ed play.
I'd like to be free to record any length of loops, and play them in a
non-quantized manner. Just a midi mappable button would do the trick.
Also, is it possible to launch an individual loop ? or must I play an
entire row every time ? If not, that'd be a nice feature.
Cheers, that's a nice piece of software !
keep up with good work !
E.:.T
Hey All,
I'm delighted to say that 5 days after announcing, Luppp has reached its
target donation!
That means that its now available under the GPLv3+ license, to everybody!
Grab the details & source from here: http://openavproductions.com/luppp
I'd like to thanks the community, for the awesome support Luppp has
recieved!
Thanks to LeatusPenguin, ZthMusic, AutoStatic, and others for beta-testing,
making this release much more polished before this release. Thanks to
Jonathan Liles for writing NTK, the user-interface toolkit behind the
OpenAV software interfaces.
Thanks to all the contributers: you are the reason this software is
available right now!
Thanks again, -Harry
Hello audio developers,
I have just updated a new release candidate for LibLo 0.28rc. Due to
a couple of bad bugs slipping into the last release I have decided to
take a more precautionary approach this time and ask for public
testing of this release candidate before a final 0.28 release.
That is to say, this release fixes several important issues from 0.27,
but is not intended for use in production until after this round of
testing.
To download liblo-0.28rc:
https://sourceforge.net/projects/liblo/files/liblo/0.28rc/liblo-0.28rc.tar.…
For more information, the liblo project page can be found at:
http://liblo.sourceforge.net/
-----------
2013-11-24: Release candidate 0.28rc
This is a release candidate 0.28rc of LibLo, the lightweight, easy to
use implementation of the Open Sound Control protocol.
Open Sound Control (OSC) is a protocol for communication among
computers, sound synthesizers, and other multimedia devices that is
designed for use over modern network transports.
This is mainly a bugfix release due to some deal breakers that
unfortunately made it through to the 0.27 release. Additionally, this
is the first release to include a modern C++11 object-oriented wrapper
for the LibLo API. Please test!
Important bug fixes:
* Fixed checking of vararg markers on 64-bit systems
* Fixed hang in TCP blocking test
* Several potential bugs prevented through static analysis
Additional changes:
* Add function lo_bundle_get_timestamp()
* Add C++11 wrapper, `lo_cpp.h', and test program
* Support for a few more build tools: clang/clang++, ccache
thank you,
Steve
Here's my first foray into the LV2 world. Kudos to the work of Steve
Harris, Nedko, Dave Robillard and Harry Van Haaren. I wrote these
initially because of a need, but maybe someone else can find use for
them also. Beta only at this stage:
https://github.com/bsjones/psi-plugins
hello,
tested successfully with a HDSP 9652.
great usefull tool !
notice that if hdspmixer has not been started after bootup (means the card is not initialized in some way), hdspdump throw no error, and creates a dump file filled with 0. It means that alsa is not throwing errors either as your programs goes nicely to the end.
I've been looking at hdspmixer code for some days now to make it console only, removing FLTK dependencies. Your program gives me motivation to go on with this hard task.
Raphaël
Le 26 nov. 2013 à 19:32, linux-audio-dev-request(a)lists.linuxaudio.org a écrit :
> Re: Headless RME HDSP/HDSPM mixer settings
As some of you know already, ive been busy porting OpenMusic to Linux
over the last months.
Theres a beta-release of OpenMusic 6.7 available as a RPM-package here:
http://repmus.ircam.fr/openmusic/linux
The standard functionality is in place. Its been tested, with most of
the standard OM-libraries from IRCAM, as well as quite many 3rd-party
libs, during the last weeks by me and others.
The development of OM for Linux is continuing in collaboration with the
main OM-developers at IRCAM.
Please check back at the download-area for updates every now and then.
Theres a mailing-list where announcements might come more often:
http://repmus.ircam.fr/openmusic/contact
OM installs and uses its source-code while running. If you want to
build your own or get into developing this further its presumably more
effective to work on a local checkout of the svn-tree, available through
the "Sources/Developer"-pane on the same page.
Please provide feedback, bug-reports, issues, questions.
Thanks,
-anders
