Hi all,
I just found this list after being directed to the IRC channel over the
weekend. I'm new here! Lately I've been dabbling in a bit of open-source
audio development (I say open-source rather than linux, because I've been
dabbling on both linux and windows).
Anyhow, amongst other things I've been trying to teach myself about DSP, so
I wrote a really (really, really, really) naive distortion plugin. I was
wondering if anyone would be interested in taking a look at it and giving
me some feedback, and tips on where to go next.
I wrote a little about it here:
http://guysherman.com/2015/08/30/my-first-ever-audio-plugin/
And the code is at: https://github.com/guysherman/si-plugins
I've got some other projects on the boil that I've been talking about with
the crew from the Ardour list, which I'll mention here when they take shape
a little more.
Cheers,
Guy.
--
Guy Sherman
*e:* guy(a)guysherman.com
*w: *http://guysherman.com
I'm finding quite a lot of occasions where variables defined as 'bool' are
sometimes being set with true or false and other times 0 or 1. On one occasion
there is something like x = n + {boolean variable}
This last one seems quite unsafe to me as I didn't think the actual value of
true and false was guaranteed.
Am I being overly cautious or should I change them all to one form or the other?
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Are there any plugin architectures that allow
input data length different than the output length
such that the 'run' function can ask for more or less
input data, for example via some kind of stream?
Instead of passing 'run' a block of data, host would
pass these streams so that 'run' can pull and push
whatever lengths it needs.
There would be compatibility information on each
stream so that other streams could accommodate.
I thought I read of an LV2 extension or something...
Or am I imagining something like Pulse?
Thanks.
Tim.
Greetings,
I am fairly new to USB dev (in linux in particular, but also in general), but I
would very much like to try to get support for the above device working in
snd-usb-audio.
- Is this an appropriate place to discuss snd-usb-audio?
- Are there any recommended reading pointers for behavior of the quirk table?
I patched parse_audio_format_rates_v2(), get_sample_rate_v2(), and
set_sample_rate_v2(), and through some sort of beginner luck was able to get
aplay audio out of the first two channels. That was incomplete hackery though
(eg fixed sample rate), and I would like to learn how to properly add quirk
support. There have been other reports that this device worked OOTB, but I
fail to see how!
I've also been examining the traffic to the device with wireshark and a
win7 vm, but the learning curve for USB is a bit steep, so I am digesting. (:
If anyone can provide suggestions on lsusb output alone, here's what I have:
http://pastebin.com/pA9MLQet
cheers,
Greg
[x-post from alsa-devel due to empty thread -
see: http://mailman.alsa-project.org/pipermail/alsa-devel/2015-July/094682.html]
Hi all
I'd like to get some feedback on GSequencer v0.7.54. Many things have
changed so far. Good real-time is still a pain especially as doing
much GUI interaction. How-ever I have coded a strategy to counter the
issue.
Here are some new features listed that should work:
* automation editor to automate ports, currently only LADSPA, DSSI and Lv2
* Configuration in place of device, pcm-channels, samplerate, buffer
size and format
* Virtual MIDI mapping to route from GSequencer to DSSI and Lv2
* Notation editor to edit notes of DSSI and Lv2 plugins
Things I'm not sure if still works:
* auto-scroll of notation editor on playback
* export to WAV files with different samplerate and format
All existing features for sure:
* sequencer editors with copy and later for paste in notation editor
* reallocate audio channels and pads
* destroy machines
* link lines
Believed to be broken:
* different threading models than super-thread with channel scope are
believed to be broken
Currently unmaintained:
* Original file format temporally replaced by a light-weight one
Note: having 128 channels on DSSI or Lv2 synths is a bit over-helming.
So you might want to adjust the channels and do MIDI mapping.
Cheers,
Joël Krähemann
The FFADO developers are pleased to announce FFADO version 2.3.0, a package
of userspace drivers for firewire audio interfaces. While there are no
significant new features in this version compared to the last, FFADO 2.3.0
contains a large number of incremental improvements. Users of FFADO are
encouraged to upgrade.
This source-only release can be downloaded from the ffado.org website at
http://ffado.org
or via the direct link:
http://ffado.org/files/libffado-2.3.0.tgz
Notable changes include:
* Configuration entries added for additional devices which work with the
generic support layer (PreSonus Studiolive 32.4.2, Presonus StudioLive
16.0.2, ICON FireXon, Onyx Blackbird and the new Onyx 1640i, among
others).
* Support added for the newer Focusrite Saffire Pro 26.
* Improved build support for various downstream consumers.
* Better routing for selected Saffire devices and the Firestudio Mobile.
* Significant cleanup and refinement of the M-Audio and Yamaha driver.
* Compilation fixes for recent versions of gcc.
* Recover from dead streams without causing jackd to shut down.
Thanks go out to the developers and users who contributed code and
information which went into this release: Kristian Amlie, Melanie Bernkopf,
David Binderman, Philippe Carriere, Yves Grenier, Florian Hofmann, Hector
Martin, Mathieu Picot, Philippe Ploquin, Stefan Richter, Takashi Sakamoto,
Jano Svitok, Karl Swisher, Steven Tonge and Jonathan Woithe.