On jeu. 19/09/13 17:50 , IOhannes m zmoelnig <zmoelnig(a)iem.at> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2013-09-19 05:31, hermann meyer wrote:
> >>
> > I'm sad to hear that. :-( Please don't let you lead from the things
> > you didn't like, let you lead from the things you like instead. I
> > guess then it's necessary to let you know that we use /as well/ a
> > fork of your work, the zita-convolver library, in the guitarix
> > project. But we leave your copyright untouched, and the fork will
> > only come in use, when the user set a explicit compile flag. We
> > didn't promote it, or force the fork. Ordinary your original code
> > is in use. We do it to use ffmpeg instead fftw3 FFT, which perform
> > better on ARM devices.
>
> but this sounds like the perfect opportunity to not do a simple fork,
> but to send patches to upstream so fons' aeolus could support both
> fftw3 and ffmpeg FFTs.
> it might be a win-win situation, where not only more than just the
> original aeolus users can profit from fons' work (because you use his
> code) but also more than just your users can profit from your work
> (because you changes are included into upstream aeolus).
I fully agree. As the main fvwm-crystal developer, I know how hard it can
be to get good users returns. I find it scary if even developers cannot
share with each others.
I begun to write my own fvwm-crystal functions because I wanted them,
and when I was done, I contacted upstream. At first, I get no answer, so
I done a fork. Some months later, it was a discussion about my fork
on fvwm-crystal email list, and that time I get in touch with upstream,
and my work was incorporated into Crystal. Form there, I am now the
main contributor. It is not always easy, but so is life.
As the main fvwm-crystal developer, I just don't have the time to check
what can be the special requirements of each distribution or each user
that use it. And I find it very sad when they make modifications and
don't contribute them. From users, I can understand that very well, but
from developers, I think they just miss a very important point about FOS :
a community is always about solidarity.
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. And it is not easy to solve if developers that make
patches just say nothing to the original developers. We are living
in an individualistic society, so are commercial softwares, but with
FOS, peoples must really take on them to communicate more about
what they are doing, that especially when they are making interesting
patches or forks.
Dominique
>
> fmasdr
> IOhannes
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Icedove - http://www.enigmail.net/ [1]
>
> iEYEARECAAYFAlI7D0UACgkQkX2Xpv6ydvTc+gCdGdTegTkJmgsRvZ5xz39AyxCe
> VEIAnRFYLyRpmcUOUsPZ8jsZ5ceuo21g
> =v6Hr
> -----END PGP SIGNATURE-----
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev [2]
>
>
>
> Links:
> ------
> [1] http://awebmail.vtx.ch/parse.php?redirect=http://www.enigmail.net/
> [2]
> http://awebmail.vtx.ch/parse.php?redirect=http://lists.linuxaudio.org/listi
> nfo/linux-audio-dev
>
On 09/20/2013 02:35 PM, Ralf Mardorf wrote:
> On Fri, 2013-09-20 at 14:14 +0200, Alex wrote:
>> I'm glad you asked! :)
>>
>> A fully functional, comprehensively tooled up (including keybinding
>> functionality for as much as possible) jack midi sequencer, that doesn't
>> do audio or plugins (we have decent apps for those already), but does
>> midi......comprehensively. (and including properly functioning MMC, MTC,
>> bank and patch management, a full set of keybinding functions for as
>> much as possible, including navigation, folder tracks (containers) for
>> handling a lot of tracks, a complete pianoroll toolset for
>> input/edit/remove including bindings for things like toggle step input,
>> just to name a few.....)
>>
>> And a gui that works, and saves position, size and midi clip values like
>> CC lanes assigned per track that display in the pianoroll (1st violins
>> track might have velocity/volume/pitchbend/modulation CC lanes, and
>> tubas might only have volume and velocity, as an example)
>>
>> Did i mention keybinding functionality for as much as possible?
>>
>> And complete non-session-manager and OSC functionality?
>>
>> That should keep you busy for a while. :)
> I would like to get this too, but + audio recording ;).
>
> Especially a mute and unmute clip function, the most missing thing for
> Qtractor, the sequencer I'm using.
>
> And this mixer thingy Cubase for the Atari does provide, to set up real
> time hardware synth editors, that can be used by a sequencer track.
> Turning of running status send to hardware synth would be nice too.
>
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-user
Ralf, we already have good audio apps (non-timeline, etc), and it's easy
to port one to the other.
Qtractor doesn't do jackmidi.
Alex.
On ven. 20/09/13 13:14 , Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
> On Fri, 2013-09-20 at 11:00 +0200, michel dominique wrote:
> > That imply we must communicate more with each other.
>
> But we all know that some people can't communicate with each other, not
> only when it comes to forks, even when reporting bugs. That's bad, but
> natural.
Communication is the ground of civilisation. Unfortunately, our society
is so individualistic that some peoples miss it even when doing FLOSS.
It is why they have to learn to communicate at the first place. And that's
not that hard, it can begin by just sending an email.
>
> Perhaps my request will get them in contact.
> https://github.com/mgavioli/oscAeolus/issues/1 [1]
That's a good initiative!
Best,
Dominique
>
> Regards,
> Ralf
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev [2]
>
>
>
> Links:
> ------
> [1]
> http://awebmail.vtx.ch/parse.php?redirect=https://github.com/mgavioli/oscAe
> olus/issues/1[2]
> http://awebmail.vtx.ch/parse.php?redirect=http://lists.linuxaudio.org/listi
> nfo/linux-audio-dev
>
Good morning
i'm trying to use a Roland R-26 as audio interface (USB).
I saw it is now officially supported in the alsa-driver repo log:
commit aa47d6014f7011b335345ce14836efe358b0cfe5
Author: Clemens Ladisch <clemens(a)ladisch.de>
Date: Sun Mar 31 23:43:12 2013 +0200
ALSA: usb-audio: add support for many Roland/Yamaha devices
Add quirks to detect the various vendor-specific descriptors used by
Roland and Yamaha in most of their recent USB audio and MIDI devices.
...
...
- Roland R-26 Recorder
So i cloned the alsa-driver repo (branch release) and run ./gitcompile.
Everything looks good and alsa force-reload worked.
$ cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version 1.0.25.
Compiled on Sep 2 2013 for kernel 3.2.0-39-lowlatency (SMP).
When the device is plugged in and selected to act as an audio interface,
dmesg says (debug=verbose):
[ 5642.186130] usb 1-5.1: new high-speed USB device number 8 using ehci_hcd
[ 5642.391666] snd-usb-audio: probe of 1-5.1:1.0 failed with error -5
[ 5642.392403] ALSA stream.c:711 >8:1:1: add audio endpoint 0xd
[ 5642.392775] ALSA stream.c:711 >8:2:1: add audio endpoint 0x8e
[ 5642.394385] usbcore: registered new interface driver snd-usb-audio
$ lsusb | grep Roland
Bus 001 Device 008: ID 0582:013e Roland Corp.
$ cat /proc/asound/cards
0 [R26AUDIO ]: USB-Audio - R-26(AUDIO)
Roland R-26(AUDIO) at usb-0000:00:0b.1-5.1, high speed
After compile, there is a clear warning:
WARNING!!! The mixer channels for the ALSA driver are muted by default!!!
**************************************************************************
You would use some ALSA or OSS mixer to set the appropriate volume.
-> alsamixer says "This sound device does not have any controls." so i
can't unmute anything there.
$ aplay a.wav
Playing WAVE 'rabe_babe.wav' : Signed 16 bit Little Endian, Rate 44100 Hz,
Stereo
-> there are no errors, but it stays like this (a.wav is a few seconds)
forever and there is no volume indication "from PC" on the device.
$ arecord -f cd b.wav
Recording WAVE 'b.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
-> no errors but the file is empty (44 bytes), the device shows active mic
level "to PC"
It doesn't work for input or output but i guess it's near working. The
only error is in dmesg (error -5 ?). Were could i go from here? Any hint
is welcome
Best regards,
Thomas
I was attracted by the small (memory and screen) footprint of JackMix, the Qt
Matrix Mixer for Jack, which makes it very useful on laptops, but needed to be
able to control it via MIDI. This lets us give performances at conferences
when we can't afford to talk the whole ensemble. We play a video along with the
live musicians feeding separate mixes to each performer and to master speakers
from multi-track video being played by the VLC Jack plugin.
Consequently, I've updated it to make the mixing elements respond to MIDI
control commands.
My updated version is here: https://github.com/nickbailey/jackmix
If the original author, Arnold Krille, is reading this, I'd really like to
email you, Arnold. There are one or two things I'd like to change but don't
yet understand the best way to do it!
Here is the NEWS file:
VERSION 0.5.0
-------------
New features this version (added by Nick):
The right-click on the matrix can be a bit fiddly to pop up the
context menu instead of the knob setting spinbox, so the following
shortcuts are now available:
* Toggle element selection with Shift-Mouse1
* Replace selected elements with Ctrl-Shift-Mouse1 in the upper-
left-most selected element
MIDI control of the mixer is now available. You can route signals
from a MIDI control surface to JackMix: it appears as "JackMix" in
the ALSA MIDI tab of QJackControl, for example. Each element now has
an extra context menu entry: "Assign MIDI Parameter". Use should be
self-evident.
Points to note:
* You can't unassign a midi parameter -- it can be set to
0 though (my control surface doesn't have controller 0;
some may I suppose).
* MIDI control parameter numbers are saved in the xml file
generated by File->Save File... menu action, but this means
there are extra XML attributes which might upset older versions
of JackMix. I've not tested this, but it might cause problems
if you aren't aware of the extra functionality.
Hello all,
zita-ajbridge-0.4.0 is now available at the usual place:
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html>
>From the README:
* The 'JackPortIsTerminal' and 'JackPortIsPhysical'
flags are set on the Jack ports.
* The correct latency value is set on the Jack ports.
This is the latency resulting from buffering and
resampling. It does not include any additional
latency due to processing by the sound card, e.g.
from anti-alias filters. This can be added using
the -I (for a2j) and -O (for j2a) options, in the
same way as for Jack's ALSA backend.
The README also explains how to test this.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Hi all,
I just joined the developers list as I've been looking into adding
Jack midi support to one of my favourite sequencers (harmonySEQ) and
need some advice related to threading and shared data. I know these
issues have come up before, specifically I found two related threads
[1][2], but I am still confused as to what would be the best approach.
(I am also new to thread programming in general.)
As this is a sequencer the main data structure is a list of patterns
where each pattern contains a list of notes. Patterns can be
manipulated while being played back. Both the GUI thread and Jack
thread should be able to modify the patterns, e.g. a midi event might
toggle a pattern on/off, the GUI can insert a note into a pattern, or
add or remove a pattern.
I've considered different approaches (separate data for each thread,
various versions of shared data), but I believe all of them make at
least two assumptions: That reading and writing byte-sized data (e.g.
a bool flag) and that updating pointers is atomic. I got a bit
confused reading this thread [2]. Are these assumptions correct?
To be more specific, one of the schemes I came up with followed the
idea of using only one shared data structure which has to be in a
consistent state at all points in time. To ensure this I would have to
be very careful as to how I update the data structure. For example, if
the GUI added or removed a note from a pattern (which might involve a
memory reallocation) it would do so by performing theses changes on a
copy of the current pattern and then replace the original pattern by
updating the pointer to this new version of the pattern. Simple
updates (e.g. turning a pattern on / off) would be performed directly
on the pattern as I consider them atomic. To keep references to
patterns throughout the code I would use some global registry, as I
cannot use pointers for they "expire" (might point to an old version
of the pattern).
Does that make sense? Are there some obvious flaws with that scheme
that I oversaw, are there better ways to go about it? I am really
quite new to this kind of programming issues, I would appreciate any
pointers and advice!
Thanks,
Burkhard
[1] http://linux-audio.4202.n7.nabble.com/Best-practice-for-sharing-complex-dat…
[2] http://linux-audio.4202.n7.nabble.com/Atomic-Operations-td58961.html
Hey everybody,
OpenAV is releasing Sorcer 1.1! Upgraded features such as a compressor and
output level provide better feedback in an all new NTK based UI! Existing
presets are remain unchanged: the compressor is off by default.
Packagers will be happy to know that Sorcer now uses Make, so packaging
should be easier.
Details available on http://openavproductions.com/sorcer
Cheers, -Harry
Hi,
I'm writing a CLI editor for the Matrix-1000. Regarding to the owner's
manual some parameters have 6 bit values, so I gave them a range from 0
to 63, for the 7 bit value I definite a range from 0 to 127. Many values
are described as "7 (Signed)". I consider those values should get a
range from -64 to 0 to +63, IOW I understand it as a two's complement,
but the editor of my Atari ST's Cubase 3.1 doesn't give them a value
from -64 to 0 to +63, instead the GUI's value range is from 0 to 127. I
suspect that the Cubase editor is mistaken, resp. the editor was build
by a "kit" and I suspect there's a limitation, it doesn't know signed
values.
My guess is, that it would be correct to assign a value range from -64
to 0 to +63. Is this correct? Or am I mistaken and the value range given
by Cubase is correct?
Regards,
Ralf
On Thu, 2013-09-12 at 14:22 +0200, Alexandre Ratchov wrote:
> On Mon, Sep 09, 2013 at 04:45:53PM +0200, Ralf Mardorf wrote:
> > Hi,
> >
> > I'm writing a CLI editor for the Matrix-1000. Regarding to the owner's
> > manual some parameters have 6 bit values, so I gave them a range from 0
> > to 63, for the 7 bit value I definite a range from 0 to 127. Many values
> > are described as "7 (Signed)". I consider those values should get a
> > range from -64 to 0 to +63, IOW I understand it as a two's complement,
> > but the editor of my Atari ST's Cubase 3.1 doesn't give them a value
> > from -64 to 0 to +63, instead the GUI's value range is from 0 to 127.
>
> I don't have a matrix-1000, but there's plenty of midi gears that
> use biased 7-bit integers instead of signed two complement. I mean:
>
> 0 -> min value
> 64 -> neutral value
> 127 -> maximum value
>
> example, a value in the [-0.5:0.5] range would be represented
> with the 7-bit number in 1/128 steps as follows:
>
> 0 -> -64/128
> 1 -> -63/128
> ...
> 64 -> 0
> 65 -> 1/128
> ...
> 127 -> 63/128
>
>
> note that 0.5 cannot be reached with this scheme; so sometimes only
> the range 1..127 of the 7-bit number is used in 1/127 steps.
>
> HTH
Thank you Alexandre,
at the moment it's possible to use -64 to +63 by signed two complement
and it's also possible to continue up to +127, assumed the two
complement should cause audible value "jumps".
I simply will connect the Matrix-1000 and then test what happens.
I found a free Windows editor that does provide -63 to +63 (no 0.5
steps) but since I run Windows in VBox, I don't know if I could get a
MIDI output to take a look at the SysEx data.
Another issue are some bit switches, e.g. for a DCO Waveform enable
bit 0 = pulse, 1 = wave and 2 = noise. For the Windows editor it's
possible to turn on pulse, wave and noise at the same time, while I
suspected that if one is turned on, the others should be turned off.
However, I will test it using the editor I've written, with the Matrix I
own.
I hoped somebody who owns a Matrix too does know, too avoid those tests
when I started writing.
If there should be the need to rewrite what already is written, it
wouldn't cause work, the actual work is to copy all parameters from the
manual and to find a way to make the Matrix's matrix clear for the
command line (without a GUI).
It's just a bash script using amidi, from the fact that I need to copy
all parameters from the manual and need to find a way to make the
Matrix's matrix clear without a GUI, the script is finished, so I easily
can test the behavior, whenever I've got some time to do it ;).
Regards,
Ralf
