Hi Lists,
a very short notice for a fully Linux-based
modular Ambisonics concert this Friday -
featuring:
* E.O.C (8 modular synths)
* AA..LL (solo, drone)
* 1)3\/1532 (solo, drone)
* TRUMMERSCHLUNK (solo, slow tech)
08.03.2019
Holzmarktstraße 25, Berlin
(Artisten-Halle)
Doors:20:00
Start:20:30
Entrance: 10 Euro
More Info:
http://hvc.berlin/https://www.inm-berlin.de/en/konzertkalender/31398/sprawl_voices_31398
Hoping to see some of you there
Henrik
--
Henrik von Coler
Elektronisches Studio, Fachgebiet Audiokommunikation
Electronic Music Studio, Audio Communication Group
Technische Universität Berlin
Fakultät I Geistes- und Bildungswissenschaften
Institut für Sprache und Kommunikation
Faculty I Humanities
Institute of Speech and Communication
Einsteinufer 17c, Sekr. EN 8, 10587 Berlin
Germany
Tel: +49 (0)30 314 22327
Fax: +49 (0)30 314 21143
voncoler(a)tu-berlin.de
www.ak.tu-berlin.de
Hi all.
As usual the second Tuesday of the month is upon us. I'll be in the
mainhall from 20:00.
See you there.
Cheers
/Daniel
PS Let's keep the follow-up discussion in the LAU thread. DS
Hi all,
I'm looking for someone to develop some HW and SW as a consultancy job
for my employer, Huawei German Research Center, Munich.
What we need is 16 channels of analog audio output (16 bit is OK,
24 preferred, 48 kHz sample rate) from a Raspberry 3B+ using the GPIO
interface, using any of I2S, I2C or SPI or whatever seems best.
You job would be to design the entire electronics, probably consisting
of an FPGA and a number of D/A converters, the PCB, and all required SW.
The SW would be the FPGA code, and an ALSA driver or any other solution
allowing to use the interface from user space.
It seems (see <https://github.com/hzeller/rpi-gpio-dma-demo>) that
more than enough bandwidth is available using the GPIO pins. Strangely
enough it also seems that using a CPU offers much better performance
than using DMA. For driving the interface you can use one CPU of the
Rpi up to 100%.
Anyone interested please get in contact with me off-list.
Ciao,
--
FA
Just a heads up for anyone likely to come across this.
It now hides some internal elements that were accessible in V2.x so you might
be advised to review your code - it bit us with Yoshimi :(
--
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.
Hi list.
When I put breakpoints in gui or non-rt audio thread code, no problems.
But when I put breakpoints in rt audio thread code, behaviour is odd.
I can continue the program and even have more breakpoints.
But when the program tries to close, it hangs inside jack_deactivate().
I must kill it and QJackCtl and finally jackd. At bit cumbersome.
Seems breaking into the program hiccups jack.
Any tips or settings I can try?
I realize pausing the app is kinda crazy and over-qualifies
as 'waiting too long in an rt thread' but it seems to
get so far and work OK but fails at the end.
Can it be helped?
Thanks.
Hi,
While not strictly Linux or "audio", I have a project that MAY
interest some folks here: For gainful employment, I'm involved with a
research project that uses the Pacarana sound engine from Symbolic
Sound. It comes with a proprietary application, Kyma (pronounced
"kee-ma"), which uses drag 'n' drop "patch bay" and a variant of
Smalltalk which Symbolic Sound has named "Capytalk". But the box also
understands OSC.
However, my access to the box is limited. So, in order to test out my
code I've built an ... emulator isn't quite the word... mock object, I
guess, to acknowledge my OSC messages with appropriate responses (but
no audio) when I'm not in the same room as the Pacarana. The code is
written in Python 3 and lives out on:
https://gitlab.com/ubuntourist/paculator
Right now the CLI stuff works well enough for my purposes, and there's
the rudiments of a GUI reproduction of Kyma's Virtual Control Surface
(VCS). The GUI portion requires PySide which requires Qt. Also, it
advertises itself via mDNS / Bonjour / Zeroconf / avahi. It lives in
the newer pipenv virtual environment.
I'm both proud of it and embarrassed by it. ;-)
Hi all.
On Tuesday the 12th of February it's again the meeting at c-base. I'll
be in the mainhall from 20:00.
As usual, let's keep the follow-up discussion in the LAU thread.
Cheers
/Daniel