Hi,
QMidiArp 0.5.2 has just seen the light of the day. It brings mainly
two improvements. One is a comeback, that of tempo changes on the fly,
and that now includes also tempo changes of a potential Jack Transport
master. Also the Jack Transport starting position is finally taken into
account, so that QMidiArp should be in sync also when starting the
transport master not at zero.
The second one is Non Session Manager support, mainly thanks to the work done by Roy Vegard Ovesen!
Note that for compiling in NSM support you will now need liblo as dependency.
Enjoy, and enjoy LAC in Graz this year
Frank
________________________________
QMidiArp is an advanced MIDI arpeggiator, programmable step sequencer and LFO.
Everything is on
http://qmidiarp.sourceforge.net
qmidiarp-0.5.2 (2013-05-09)
New Features
o Tempo changes are again possible while running, both manually or by
a Jack Transport Master
o Jack Transport position is now taken into account when starting,
QMidiArp used to start always at zero
o Muting and sequencer parameter changes can be deferred to pattern
end using a new toolbutton
o Modules in the Global Storage window have mute/defer buttons
o Global Storage location switches can be set to affect only the pattern
o Non Session Manager support with "switch" capability (thanks to
Roy Vegard Ovesen)
General Changes
o NSM support requires liblo development headers (liblo-dev package)
Hey Everybody,
I'm happy to announce OpenAV productions: http://openavproductions.com
OpenAV productions is a label under which I intend to release my
linux-audio software projects. The focus of the software is on the workflow
of creating live-electronic music and video.
The release system for OpenAV productions is one based on donations and
time, details are available on http://openavproductions.com/support
Sorcer is a wavetable synth, and is ready for release. Check out the
interface and demo reel on http://openavproductions.com/sorcer
Greetings from the LAC, -Harry
Hello everyone,
lately I had to fight big XRUN troubles, and thanks to this forum I
finally solved that. This excellent thread saved me:
http://linuxaudio.org/mailarchive/lau/2012/9/5/192706
On my long quest, I tried to see a little bit more what happened with
the IRQs on my system. I searched for a kind of 'top' utility to monitor
the interrupts, but the only apps I found were either deprecated, or
missed some cool features.
So, I ended up writing my own tool to monitor the file /proc/interrupts.
It's available a this address:
https://gitorious.org/elboulangero/itop
As its name indicates, it behaves pretty much like top, but for interrupts.
It's quite a simple thing, that I tried to enhance a bit with some cool
features:
+ refresh period can be specified.
+ two display modes: display interrupts for every CPU, or only a sum
of all CPU.
+ display every interrupt (sorted like /proc/interrupts), or only
active interrupts (sorted by activity).
+ in case the number of interrupts changes during the execution of
itop (due to a rmmod/modprobe), it's handled without any fuss.
+ command-line options are also available as hotkeys for convenience.
+ at last, the program display a summary on exit. The idea is that
this summary could be copied/pasted in emails to help debugging.
If anyone is interested, feel free to try and comment !
Cheers
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
>
>> In my lv2 plugin, I need to communicate information from the DSP to
>> the UI, but I don't want to break the DSP/UI separation principle (no
>> Instance or Data access). On top of that, I'm using LVTK.
> he, he, yeah it can get a little confusing... maybe this will help.
> // you're sending things in an atom sequence so get the size information
> // from the port buffer
>
> LV2_Atom_Sequence* aseq = (LV2_Atom_Sequence*) p (p_notify);
> m_forge->set_buffer ((uint8_t*) aseq, aseq->atom.size);
>
> m_forge->sequence_head (m_notify_frame, 0);
>
> // sequences need a timestamp for each event added
> m_forge->frame_time (0);
>
> // after forging a frame_time, just write a normal float (no blank object needed)
>
> m_forge->write_float (1604);
> Your ttl file has atom:Float as the buffer type. I've never used
> anything besides atom:Sequence. I imagine this buffer type doesn't need a
> sequence head forged first. Maybe David will jump in on how atom:Float
> bufferType'd ports are supposed to forged into and out of.
Ok, so I changed my code the way you proposed (with switching in the
ttl to Sequence), but still don't manage to make it work.
I'm wondering if there isn't something wrong with the way I setup the
Forge in the first place. I'm a bit confused with the way to interact
wiith the map object in LVTK.
Scope::Scope(double rate) : Plugin<Scope, URID<true>,
Options<true>>(p_n_ports)
{
m_forge = new AtomForge(p_map);
}
void Scope::run(uint32_t nframes)
{
// you're sending things in an atom sequence so get the size information
// from the port buffer
LV2_Atom_Sequence* aseq = (LV2_Atom_Sequence*) p (p_notify);
m_forge->set_buffer ((uint8_t*) aseq, aseq->atom.size);
m_forge->sequence_head(m_notify_frame, 0);
// sequences need a timestamp for each event added
m_forge->frame_time(0);
m_forge->write_float(1604);
}
> I recommend, if you want to use LVTK to do atom forging, that you subclass
> lvtk::AtomForge and add appropriate methods to it...
>
> Here's a snippet that shows how to write patch get/set messages with a
> subclassed AtomForge. It also shows how to write raw midi.
>
> http://pastebin.com/C1LYtXpv -- the code in there uses small uses the
> nullptr macro. just change those to "0" if you're not using c++11
Could you tell me the advantages of doing that?
But I had a look at the code, I still need to understand how to work
with LV2_URID_Map in LVTK (I cannot find any examples using it).
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."
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.
The -users list is good for asking users and interested parties questions.
I will try to announce more patches / code, to contribute upstream, and
hopefully benefit the community.
Cheers, -Harry
Hi all,
Due to excessive posts - in particular on the linux-audio-user email
list, we are going to rate-limit the number of emails to
13 emails per user per 24 hours
with direct follows-up replies to self counting twice.
It is not unreasonable to assume that a single user posting more than
12 emails per day is either involved in a heated flame-war or otherwise
disrupting reasonable discussion. Neither of which is acceptable on the
LA email lists.
We understand that some communication requires rapid exchange of many
small snippets and recommend users who need to regularly post short
messages many times per day to rather use services such as twitter, IRC
or simply private email. The LA email lists are mainly intended for
discussion, questions & answers, sharing and preservation of knowledge.
Note that there are currently over 3000 persons subscribing to the LA
lists, every single email sent to the list will result in 3000+ forwards
and be archived in various places on the web.
Offenders will be notified with a warning message with the 10th email
within a day and after the 13th email temporarily banned for 6 hours
from further posting to the given email list.
Feel free to comment on this email here on this list, but official
inquires should be addressed to members of the consortium. See
http://linuxaudio.org/contact
The system will be activated on 31/Oct/2013 if not vetoed. The actual
rate-limit may also be adjusted over time to reflect list-behaviour.
yours truly,
robin
Hi everyone,
In my lv2 plugin, I need to communicate information from the DSP to
the UI, but I don't want to break the DSP/UI separation principle (no
Instance or Data access). On top of that, I'm using LVTK.
The type of data I'm trying to move is a Vector of Float (buffer type
Sound in the ttl) - but even basic information on how to transfer a
Float from the DSP to the UI would be valuable.
What I have do so far in the DSP (run method)
m_forge->set_buffer((uint8_t*)p(p_notify), sizeof(float));
//p_notify being the atom port
m_forge->sequence_head(m_notify_frame, 0);
ForgeFrame p_frame;
Atom p_msg = m_forge->write_blank(p_frame, 1, urids.atom_Float);
m_forge->property_head(urids.atom_value, 0);
m_forge->write_float(1604); //test data i'm trying to move
m_forge->pop(p_frame);
In my UI, I just want to see if I receive this data
In the port_event method, at the moment the only thing I'm doing is:
std::cout << port << " - " << format << std::endl;
The port is defined in the TTL as follows:
a lv2:OutputPort, atom:AtomPort ;
atom:bufferType atom:Float ;
atom:supports <http://lv2plug.in/ns/ext/patch#Message> ;
lv2:index 1 ;
lv2:symbol "notify" ;
lv2:name "Notify" ;
At the moment, the code compiles and runs without crashing (yeah!),
but nothing happens (boo!).
Would you guys have any ideas?
Thanks in advance,
Aurélien
Hi all.
Ive been working on a linux-port of IRCAMs OpenMusic lately, and think
its approaching a useful state now.
I would very much appreciate it if some of the brave ones out there did
some testing and sent me feedback:
http://forge.ircam.fr/p/OM6/downloads/label/421/
The tarball you'll find there includes the OM-6.7 image, source code, a
README and the various resources it uses (.so's, libs, fonts, icons,
help-files, tutorials, other).
This beta is not prepared to be installed anywhere, only to be run from
inside the directory where you unpack it (type ./OM_6.7_beta_4 ... ).
Plan is to make an installable version once the dust settles some.
Theres one thing which needs installing to work however, the music-fonts
used in the various editors and factories etc. Theres an .rpm here:
http://forge.ircam.fr/p/OM6/downloads/get/omfonts-1.0-1.noarch.rpm.zip
- which hopefully takes care of the fonts (theyre also available for
manual install in the tarball). The .rpm installs them (4 .ttf-files)
inside its own folder /usr/share/fonts/omfonts/*
The present version uses JACK for audio + midi I/O, and will try to
start a JACK server if its not already running.
To get any sound from the usual midi-ports, the linux-port uses
libfluidsynth, and attempts to load one of the standard soundfonts into
it. However you should be able to route midi-output to any client you
prefer (with jack-midi support).
Thanks for any feedback.
Cheers,
-anders
