QMidiArp 0.6.0 is out, since of course it cannot miss the huge TGV train of Q-Application updates just racing by for the new year!
This release includes LV2 plugins of the three QMidiArp modules. They are synchronizable to the transport info provided by different hosts in different ways, and they work well with the new Qtractor, thanks to Rui for updates regarding this.
I don't claim that I have fully understood LV2 host-GUI communication, but I found the recent sisco plugin by Robin Gareaus very instructive for this, thanks!
Happy new year!
Frank
---------------------------------------
http://qmidiarp.sourceforge.net
Direct download:
http://sourceforge.net/projects/qmidiarp/files/qmidiarp/0.6.0/qmidiarp-0.6.…
----------------------------------------
qmidiarp-0.6.0 (2014-01-01)
New Features
 o LV2 Plugins are now available for Arp, LFO and Seq modules
   - They have full functionality as known from the standalone
     application except MIDI control, which can be provided by the host
   - The LFO plugin also has a LV2 control output scaled from 0 to 1
   - When the 'Sync to host' option is checked, the plugins support
     transport LV2 atom data from hosts as well as host transport
     information available from designated lv2 time ports (Qtractor,
     thanks Rui!)
   - Arp pattern presets are available in the LV2 module but cannot be
     written to the .qmidiarprc file. This has to be done with the
     standalone application
   - On hosts with small atom port capacities that do not honor the
     lv2 rsz:MinimumSize property, there will be issues with displaying
     very large LFO waveforms
   - Features of QMidiArp beyond the modules themselves (including
     global storage) are not available
Fixed Bugs
 o Trying to open an inexistent file from the recent files menu led to
   crash (reported by Frank Neumann)
Hello !
I'm currently trying to make an arduino controller that'd allow me to
control easily effects and such with only a few rotary encoders, without
the tedious mapping.
So, basically, I need to get the parameters FROM the programs (when
selected or sweeping though them thanks to a button) and either change
the CC/OSC accordingly on the midi/osc controller or use mididings (or
equivalent) to map things properly.
Simply put, is there a way to get a list of hosts, a list of effects
within host, a list of parameters within effect, and the value of a
given parameter ? Oh. And the names or any kind of ID would be nice.
(Male and Falktx, I think you can help me with this...)
Thanks a lot for you help !
Tumulte
Hello LAD, I'm working in company which is developing a guitar pedal board
which runs Linux (arch) and my task now is to make the kernel's usb audio
driver more appropriate to our sound card. I'm kinda lost in this since i
have a brief knowledge on usb protocol so I was hoping that you could give
me some directions on how can I optimize the driver latency wise, any tips?
Att,
Lucas
Hi all,
I am pleased to announce that a new version of aubio, 0.4.0, has been released.
aubio is a library of functions to perform audio feature extractions such as:
- note onset detection
- pitch detection
- beat tracking
- MFCC computation
- spectral descriptors
The core library, written in C, focuses on speed and portability. It is known
to run on most modern operating systems, including Linux, Mac OS X, Windows,
Android, and iOS.
A new python module, rewritten from scratch, gives access to the features of
aubio's core library from within Python. Tightly integrated with Python NumPy,
the aubio python module provides an efficient way to extract features from
audio streams as well as to design new algorithms.
To find out more about aubio and this release:
Project homepage:
http://aubio.org/
Post announcing aubio 0.4.0:
http://aubio.org/news/20131217-1900_aubio_0.4.0
ChangeLog for aubio 0.4.0:
http://aubio.org/pub/aubio-0.4.0.changelog
Source tarball, signature and digests:
http://aubio.org/pub/aubio-0.4.0.tar.bz2http://aubio.org/pub/aubio-0.4.0.tar.bz2.aschttp://aubio.org/pub/aubio-0.4.0.tar.bz2.md5http://aubio.org/pub/aubio-0.4.0.tar.bz2.sha1
API Documentation:
http://aubio.org/doc/latest/
Merry hacking!
Paul
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