Re: [LAD] 802.11n sound card
On 12/23/2009 09:40 AM, Jörn Nettingsmeier wrote: Patrick Shirkey wrote: Hi, I had a thought that maybe the network sound card should not be using ethernet but instead wireless 802.11n. The ralink rt2870 chipset is well supported at full 300Mb/s on Linux and has open source drivers. I think this would open up a lot of opportunities with a wireless sound card. I'm not sure how many are on the market right now but I haven't heard of any yet so there is a big opportunity there to fill a gap. low latency audio over wireless is fundamentally impossible. it's a shared medium, pretty much like thicknet or any other hub or bus network. if two endpoints ever send at the same time (and they will), the packets will clash and trigger resends after a non-deterministic delay (so as to avoid endless re-clashing if two endpoints happen to be in sync). the only thing that would work over wireless is heavily-buffered media center stuff for consumers, because nobody cares if there's half a second delay between your pressing play and the start of the movie. So there's absolutely no way that a keyboard, pc, mixer, speaker set transferring data over 802.11n could be made to work? For example in a home studio setting... Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] 802.11n sound card
On Wednesday 23 December 2009 09:12:24 Patrick Shirkey wrote: On 12/23/2009 09:40 AM, Jörn Nettingsmeier wrote: Patrick Shirkey wrote: I had a thought that maybe the network sound card should not be using ethernet but instead wireless 802.11n. The ralink rt2870 chipset is well supported at full 300Mb/s on Linux and has open source drivers. I think this would open up a lot of opportunities with a wireless sound card. I'm not sure how many are on the market right now but I haven't heard of any yet so there is a big opportunity there to fill a gap. low latency audio over wireless is fundamentally impossible. it's a shared medium, pretty much like thicknet or any other hub or bus network. if two endpoints ever send at the same time (and they will), the packets will clash and trigger resends after a non-deterministic delay (so as to avoid endless re-clashing if two endpoints happen to be in sync). the only thing that would work over wireless is heavily-buffered media center stuff for consumers, because nobody cares if there's half a second delay between your pressing play and the start of the movie. So there's absolutely no way that a keyboard, pc, mixer, speaker set transferring data over 802.11n could be made to work? For example in a home studio setting... There is no way to make it work with guaranteed low latency. You need somewhat low latencies to play the keyboard to other music. And you need it guaranteed unless you always record xruns and gaps as part of your musical experience... And even then its wireless and using a frequency-range used by almost all other people around you. Just count the wireless networks in your flat provided you live in a flat with other people living upstairs/downstairs/next to you. And then try to get a fast, non-interrupted stream (latency about 20ms or shorter for real playing). And then remember Jörn in that it might be illegal to shoot your neighbours... Have fun, Arnold signature.asc Description: This is a digitally signed message part. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI
On Tue, Dec 22, 2009 at 07:57:27PM +, Bob Ham wrote: It exists quite clearly in my mind. I've also made some designs on paper and put them here: http://pkl.net/~node/software/lash/lash-2.jpeg Worst draft I've ever seen. If you can't even be bothered to clearly write down your goals... Sorry, I cannot comment any further, it's just ridiculous. SCNR -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI
Bob Ham r...@bash.sh writes: On Tue, 2009-12-22 at 23:21 +0200, Nedko Arnaudov wrote: Hi Bob, thanks for commenting on LADI stuff The huge, major weak point that would prevent me from investing myself in LADI is the use of D-Bus which requires an extra, external layer in order to perform routing between objects on different buses. See my previous mail on the subject here: http://lalists.stanford.edu/lad/2009/11/0350.html From what Nedko has said on IRC, I believe LADISH has such a layer. D-Bus *can* span over multiple hosts. The main issue isn't whether D-Bus clients can connect to buses on a different host. The main issue is whether D-Bus clients connected to one bus can send messages to objects on a different bus. Applications can connect to multiple buses. Even applications that don't interract with remote machines do it. There are two standard local buses, the session bus and the system bus. Here is a screenshot of a dbus application called d-feet that shows two buses connected: http://www.j5live.com/wp-content/uploads/2007/12/d-feet-016-execute.png I was actually labouring under the impression that D-Bus as-is could cope with connecting to remote hosts because it uses sockets. That this isn't the case is, in fact *another* problem with D-Bus. D-Bus clients can't send messages to objects on remote buses. As-is, they can't even connect to buses on remote hosts. Shocking. I already replied to this: http://lalists.stanford.edu/lad/2009/12/0296.html -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgptRE5h3zwD0.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] [ANN] jack_capture V0.9.36 and Ceres V0.48
Download from: http://archive.notam02.no/arkiv/src/?C=M;O=D jack_capture jack_capture is a program for recording soundfiles with jack. Its default operation is to capture whatever sound is going out to your speakers into a file, but it can do a number of other operations as well. 0.9.32 - 0.9.36 * Add support for OGG (requires sndlib=1.0.18) * Check if file format is supported by sndlib before creating file * Added auto-support for WVE, MPC2K and RF64. (untested) * Reset terminal colors when exiting. * Check dependencies for various programs in the Makefile * Tried to make it even more clear (if that's possible) that 'jack_capture --port system:playback_1 --port system:playback_2' does exactly the same as the default. * Added untested patch from Orcan Ogetbil to make jack_capture compile on a ppc64 platform. In case jack_capture is ran on a ppc64 platform, a warning is printed during runtime. * Clearing up licenses * A fix for open() from Florian Faber. * A couple of gui fixes from Orcan Ogetbil. Ceres Ceres is a large program for doing various sound effects in the frequency domain and displaying sonograms. The program has been developed for about 13 years, and is mainly made by Øyvind Hammer with contributions from Jonathan Lee, Stanko Juzbasic and many others. 0.46 - 0.48: -Various fixes to make it build with fc11 -Include openmotif to make it easier to build -Various makefile fixes ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI
On Wed, 2009-12-23 at 13:28 +0200, Nedko Arnaudov wrote: Bob Ham r...@bash.sh writes: On Tue, 2009-12-22 at 23:21 +0200, Nedko Arnaudov wrote: D-Bus *can* span over multiple hosts. The main issue isn't whether D-Bus clients can connect to buses on a different host. The main issue is whether D-Bus clients connected to one bus can send messages to objects on a different bus. Applications can connect to multiple buses. Even applications that don't interract with remote machines do it. There are two standard local buses, the session bus and the system bus. Here is a screenshot of a dbus application called d-feet that shows two buses connected: That application will necessarily have two connection objects within it (eg, DBusGConnection,) encapsulating connections to the two buses. If you could have just one client object and use it to send messages to objects on both buses, that would be great. Unfortunately, that isn't what D-Bus does. I was actually labouring under the impression that D-Bus as-is could cope with connecting to remote hosts because it uses sockets. That this isn't the case is, in fact *another* problem with D-Bus. D-Bus clients can't send messages to objects on remote buses. As-is, they can't even connect to buses on remote hosts. Shocking. I already replied to this: My comment was less a criticism of your approach to LADISH development and more a general criticism of using D-Bus for a network-wide audio session system. -- Bob Ham r...@bash.sh ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI
On Wed, 2009-12-23 at 11:58 +0100, Adrian Knoth wrote: On Tue, Dec 22, 2009 at 07:57:27PM +, Bob Ham wrote: It exists quite clearly in my mind. I've also made some designs on paper and put them here: http://pkl.net/~node/software/lash/lash-2.jpeg Worst draft I've ever seen. If you can't even be bothered to clearly write down your goals... There seems to be some confusion here. Those are some sketches from my personal notebook to aid in my thinking. They were scanned in and put on a web server to supplement IRC discussions in the past. They were posted here in an effort to fully communicate the amount and status of work on JIZZ. These sketches are not a draft of any kind document. Their content is not meant to aid in the communication of ideas to fellow LAD members. You are absolutely right, I haven't been bothered to clearly write down the goals, or any other ideas related to JIZZ, that currently exist in my head. Alas, my time here is finite. -- Bob Ham r...@bash.sh ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Development Release - JACK-sync'd Arpeggiator - arpage
Apart from being unconcentrated, thus I allowed checkinstall to name the package for arpage branches_0.1-1_amd64.deb :D, there's a serious issue. spinymouse-s...@64studio:/usr/src/arpage/branches$ jackd -Rdalsa -dhw:0 -r96000 -p512 -n2 -Xseq jackdmp 1.9.3 spinymouse-s...@64studio:/usr/src/arpage/branches$ arpage terminate called after throwing an instance of 'Gtk::BuilderError' Aborted spinymouse-s...@64studio:/usr/src/arpage/branches$ arpage --help terminate called after throwing an instance of 'Gtk::BuilderError' Aborted The used distro is 64 Studio 3.0-beta3 amd64. I repeated ./configure and I add the output of the original make and checkinstall, those were still available, maybe you are able to see something here: spinymouse-s...@64studio:/usr/src/arpage/branches$ ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for style of include used by make... GNU checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking for library containing strerror... none required checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking dependency style of gcc... (cached) gcc3 checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for LC_MESSAGES... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking for ngettext in libc... yes checking for dgettext in libc... yes checking for bind_textdomain_codeset... yes checking for msgfmt... /usr/bin/msgfmt checking for dcgettext... yes checking if msgfmt accepts -c... yes checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking whether NLS is requested... yes checking for intltool = 0.35.0... 0.40.5 found checking for intltool-update... /usr/bin/intltool-update checking for intltool-merge... /usr/bin/intltool-merge checking for intltool-extract... /usr/bin/intltool-extract checking for xgettext... (cached) /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking for msgfmt... (cached) /usr/bin/msgfmt checking for gmsgfmt... (cached) /usr/bin/msgfmt checking for perl... /usr/bin/perl checking for perl = 5.8.1... 5.8.8 checking for XML::Parser... ok checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for a sed that does not truncate output... /bin/sed checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 98304 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... yes checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for ar... ar checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for dlfcn.h... yes checking whether we are using the GNU C++ compiler... (cached) yes checking whether g++ accepts -g... (cached) yes checking dependency style of g++... (cached) gcc3 checking how to run the C++ preprocessor... g++ -E checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC
Re: [LAD] Development Release - JACK-sync'd Arpeggiator - arpage
This looks related too: mus...@scrapyard:~/SRC/BLEEDINGEDGE/arpage/branches$ src/arpage (arpage:4581): Gtk-CRITICAL **: gtk_tree_model_get_n_columns: assertion `GTK_IS_TREE_MODEL (tree_model)' failed (arpage:4581): Gtk-CRITICAL **: gtk_combo_box_set_row_span_column: assertion `row_span = -1 row_span col' failed (arpage:4581): Gtk-CRITICAL **: gtk_tree_model_get_n_columns: assertion `GTK_IS_TREE_MODEL (tree_model)' failed (arpage:4581): Gtk-CRITICAL **: gtk_combo_box_set_column_span_column: assertion `column_span = -1 column_span col' failed (arpage:4581): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated ... (arpage:4581): gtkmm-CRITICAL **: gtkmm: object `arp1eighth' not found in GtkBuilder file. (arpage:4581): gtkmm-CRITICAL **: gtkmm: Gtk::Buidler: widget `arp1eighth' was not found in the GtkBuilder file, or the specified part of it. ** (arpage:4581): CRITICAL **: Gtk::Builder::get_widget(): dynamic_cast failed. (arpage:4581): gtkmm-CRITICAL **: gtkmm: object `arp1dottedeighth' not found in GtkBuilder file. (arpage:4581): gtkmm-CRITICAL **: gtkmm: Gtk::Buidler: widget `arp1dottedeighth' was not found in the GtkBuilder file, or the specified part of it. ** (arpage:4581): CRITICAL **: Gtk::Builder::get_widget(): dynamic_cast failed. (arpage:4581): gtkmm-CRITICAL **: gtkmm: object `arp1eighthtriplet' not found in GtkBuilder file. (arpage:4581): gtkmm-CRITICAL **: gtkmm: Gtk::Buidler: widget `arp1eighthtriplet' was not found in the GtkBuilder file, or the specified part of it. ** (arpage:4581): CRITICAL **: Gtk::Builder::get_widget(): dynamic_cast failed. (arpage:4581): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated ... Segmentation fault On 23/12/2009, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: Apart from being unconcentrated, thus I allowed checkinstall to name the package for arpage branches_0.1-1_amd64.deb :D, there's a serious issue. spinymouse-s...@64studio:/usr/src/arpage/branches$ jackd -Rdalsa -dhw:0 -r96000 -p512 -n2 -Xseq jackdmp 1.9.3 spinymouse-s...@64studio:/usr/src/arpage/branches$ arpage terminate called after throwing an instance of 'Gtk::BuilderError' Aborted spinymouse-s...@64studio:/usr/src/arpage/branches$ arpage --help terminate called after throwing an instance of 'Gtk::BuilderError' Aborted The used distro is 64 Studio 3.0-beta3 amd64. I repeated ./configure and I add the output of the original make and checkinstall, those were still available, maybe you are able to see something here: spinymouse-s...@64studio:/usr/src/arpage/branches$ ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for style of include used by make... GNU checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking for library containing strerror... none required checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking dependency style of gcc... (cached) gcc3 checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for LC_MESSAGES... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking for ngettext in libc... yes checking for dgettext in libc... yes checking for bind_textdomain_codeset... yes checking for msgfmt... /usr/bin/msgfmt checking for dcgettext... yes checking if msgfmt accepts -c... yes checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking whether NLS is requested... yes checking for intltool = 0.35.0... 0.40.5 found
Re: [LAD] LADI
On Wed, 23 Dec 2009, Bob Ham wrote: It exists quite clearly in my mind. I've also made some designs on paper and put them here: http://pkl.net/~node/software/lash/lash-2.jpeg Worst draft I've ever seen. If you can't even be bothered to clearly write down your goals... There seems to be some confusion here. Those are some sketches from my Bob... the end of the message was SCNR which means Sorry, Could Not Resist. I think he was just ribbing you. -gabriel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI
On Wed, 2009-12-23 at 07:43 -0600, Gabriel M. Beddingfield wrote: On Wed, 23 Dec 2009, Bob Ham wrote: It exists quite clearly in my mind. I've also made some designs on paper and put them here: http://pkl.net/~node/software/lash/lash-2.jpeg Worst draft I've ever seen. If you can't even be bothered to clearly write down your goals... There seems to be some confusion here. Those are some sketches from my Bob... the end of the message was SCNR which means Sorry, Could Not Resist. I think he was just ribbing you. I can see now. D'oh! :-) -- Bob Ham r...@bash.sh ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] jcgui-0.4 initial release
Hi all I would announce the release of Jc_Gui. It's a little host wrapped around the fantastic convolution engine from Fons Adriaensen called jconvolver (zita-convolver) What is it for ? It's designed to search/load and run IR-*.wav files on a local machine with jconvolver. It include a settings widget, were gain, delay, min/max mem and mode can set and the used wave file and a part of it (offset/length) could choosed. As default, the min mem is set to your jack frame rate, the max mem is set to the file length. Those settings will saved in a config file, and used to start jconvolver. Jc_Gui itself provide a Stereo Host, with master gain, tone (bass,middle,high)controllers, balance slider, and for the output to jconvolver per channel delay and gain controllers, and a wet/dry slider to mix the output from jconvolver with the original source. So, you need only to connect Jc_Gui with your in/out put ports, (Jc_Gui provide a port map there for), and can then load your IR files and start stop jconvolver easy over the Gui. The configurations can saved in presets, to reload them easy. What isn't it for ? It's a 2 Channel thing only, you can't make multi channel settings with this jcgui. project page : http://jcgui.sourceforge.net/ download : https://sourceforge.net/projects/jcgui/ enjoy hermann ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jcgui-0.4 initial release
Hermann, nice work, and thanks. Runs fine here on Gentoo 64bit. Alex. On Wed, Dec 23, 2009 at 3:01 PM, hermann brumm...@web.de wrote: Hi all I would announce the release of Jc_Gui. It's a little host wrapped around the fantastic convolution engine from Fons Adriaensen called jconvolver (zita-convolver) What is it for ? It's designed to search/load and run IR-*.wav files on a local machine with jconvolver. It include a settings widget, were gain, delay, min/max mem and mode can set and the used wave file and a part of it (offset/length) could choosed. As default, the min mem is set to your jack frame rate, the max mem is set to the file length. Those settings will saved in a config file, and used to start jconvolver. Jc_Gui itself provide a Stereo Host, with master gain, tone (bass,middle,high)controllers, balance slider, and for the output to jconvolver per channel delay and gain controllers, and a wet/dry slider to mix the output from jconvolver with the original source. So, you need only to connect Jc_Gui with your in/out put ports, (Jc_Gui provide a port map there for), and can then load your IR files and start stop jconvolver easy over the Gui. The configurations can saved in presets, to reload them easy. What isn't it for ? It's a 2 Channel thing only, you can't make multi channel settings with this jcgui. project page : http://jcgui.sourceforge.net/ download : https://sourceforge.net/projects/jcgui/ enjoy hermann ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev -- www.openoctave.org midi-subscr...@openoctave.org development-subscr...@openoctave.org ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] 802.11n sound card
On Wed, Dec 23, 2009 at 4:08 AM, Arnold Krille arn...@arnoldarts.de wrote: And then remember Jörn in that it might be illegal to shoot your neighbours... my impression has been that the best musicians always take risks which pay off, sometimes! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] ALSA autoconnect
Suppose you wanted a soft-synth to be instantly playable at startup (given the option: '--autoconnect') then what would be the ALSA functions for: 1) Saving the current live connection at exit (if any.) 2) Restoring the above (saved information.) /j ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] ALSA autoconnect
On Wed, 2009-12-23 at 17:34 +0100, Jens M Andreasen wrote: ... then what would be the ALSA functions for: Should be: ... then what would be the ALSA /MIDI/-functions for: ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jcgui-0.4 initial release
Am Mittwoch, den 23.12.2009, 17:33 +0100 schrieb Ralf Mardorf:
Hi Hermann :)
GTK isn't my friend today. Building the GUI failed :(. Any hints?
I like Fons' jconv a lot, but because of the missing GUI I prefer to use
linuxDSP SR-2A. When I saw the screenshots of the GUI you made I was
happy, but now ...
spinymouse-s...@64studio:/usr/src/jcgui-0.4$ ./waf configure
Checking for program g++ : ok /usr/bin/g++
Checking for compiler version : ok 4.2.4
Checking for program cpp : ok /usr/bin/cpp
Checking for program ar : ok /usr/bin/ar
Checking for program ranlib : ok /usr/bin/ranlib
Checking for g++ : ok
Checking for jack = 0.109.1 : ok
Checking for sndfile = 1.0.17 : ok
Checking for gtk+-2.0 = 2.12.0 : ok
==
Jc_Gui 0.4
C++ flags : -O3 -march=native -Wall
Install prefix : /usr/local
Install binary : /usr/local/bin
Jc_Gui share directory : /usr/local/share/Jc_Gui
Jc_Gui pixmaps directory : /usr/local/share/pixmaps
Configuration finished successfully (00:00:00); project is now ready to
build.
spinymouse-s...@64studio:/usr/src/jcgui-0.4$ ./waf build
[ 1/16] cxx: src/gx_globals.cpp - build/default/src/gx_globals_1.o
[ 2/16] cxx: src/gx_child_process.cpp -
build/default/src/gx_child_process_1.o
[ 3/16] cxx: src/gx_engine.cpp - build/default/src/gx_engine_1.o
[ 4/16] cxx: src/gx_main_interface.cpp -
build/default/src/gx_main_interface_1.o
[ 5/16] cxx: src/gx_gui_helpers.cpp - build/default/src/gx_gui_helpers_1.o
[ 6/16] cxx: src/gx_jack.cpp - build/default/src/gx_jack_1.o
[ 7/16] cxx: src/gx_jconv_settings.cpp -
build/default/src/gx_jconv_settings_1.o
[ 8/16] cxx: src/gx_preset.cpp - build/default/src/gx_preset_1.o
[ 9/16] cxx: src/gx_sndfile.cpp - build/default/src/gx_sndfile_1.o
[10/16] cxx: src/gx_system.cpp - build/default/src/gx_system_1.o
[11/16] cxx: src/gx_ui.cpp - build/default/src/gx_ui_1.o
[12/16] cxx: src/GtkFastMeter.cpp - build/default/src/GtkFastMeter_1.o
[13/16] cxx: src/GtkRegler.cpp - build/default/src/GtkRegler_1.o
../src/GtkFastMeter.cpp: In function ‘gboolean
vertical_expose(GtkFastMeter*, GdkEventExpose*)’:
../src/GtkFastMeter.cpp:468: error: ‘gtk_widget_get_window’ was not
declared in this scope
Oh, shi* that's a funktion comes with Gtk+2.14, I have replace
(all :-)) of them with, I have belive, . . . .
You can replace line 468 in /src/GtkFastMeter.cpp
GdkWindow* window = gtk_widget_get_window(GTK_WIDGET(fm));
with
GdkWindow* window = GTK_WIDGET(fm)-window;
that will do it for Gtk+2.12
please let me know when you run in more issues,
regards hermann
Build failed
- task failed (err #1):
{task: cxx GtkFastMeter.cpp - GtkFastMeter_1.o}
OT:
A note to the coders. We users most times prefer dummy proved
configurations. It's not always so easy to solve an issue like it was in
this case.
http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html
$ make
g++ [snip] -march=i686 -c -o zita-convolver.o zita-convolver.cc
zita-convolver.cc:1: error: CPU you selected does not support x86-64
instruction set
make: *** [zita-convolver.o] Error 1
$ hwinfo --cpu
[snip]
Arch: X86-64
Vendor: AuthenticAMD
Model: 15.107.2 AMD Athlon(tm) X2 Dual Core Processor BE-2350
Features:
fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,rdtscp,lm,3dnowext,3dnow,rep_good,extd_apicid,pni,cx16,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,3dnowprefetch
[snip]
$ gedit Makefile
$ make
g++ [snip] -march=athlon64 -c -o zita-convolver.o zita-convolver.cc
g++ -shared -Wl,-soname,libzita-convolver.so.2 -o
libzita-convolver.so.2.0.0 zita-convolver.o -lfftw3f -lpthread
$ sudo checkinstall
$ sudo make clean
For zita-resampler libs configuration is fine by default, but for the
app I got
$ make
g++ -O3 -Wall -MMD -MP -DVERSION=\0.2.0\ -c -o resample.o resample.cc
g++ -L/usr/local/lib64 -o resample resample.o -lzita-resampler -lsndfile
-lpthread -lrt
/usr/bin/ld: cannot find -lzita-resampler
collect2: ld returned 1 exit status
make: *** [resample] Error 1
Dunno what to do, but I guess this is not needed for jconv ;).
Jconv's make configuration is fine :).
Cheers,
Ralf
alex stone wrote:
Hermann, nice work, and thanks. Runs fine here on Gentoo 64bit.
Alex.
On Wed, Dec 23, 2009 at 3:01 PM, hermann brumm...@web.de wrote:
Hi all
I would announce the release of Jc_Gui.
It's a little host wrapped around the fantastic convolution engine from
Fons Adriaensen called jconvolver (zita-convolver)
What is it for ?
It's designed to search/load and run IR-*.wav files on a local machine
with jconvolver. It include a settings widget, were gain, delay, min/max
mem and mode can set and the used wave file and a part of it
(offset/length) could choosed.
As default, the min mem is set to your jack frame rate, the max mem is
set to the file length.
Those settings will saved in a config
Re: [LAD] ALSA autoconnect
On Wed, Dec 23, 2009 at 11:34 AM, Jens M Andreasen jens.andrea...@comhem.se wrote: Suppose you wanted a soft-synth to be instantly playable at startup (given the option: '--autoconnect') then what would be the ALSA functions for: 1) Saving the current live connection at exit (if any.) 2) Restoring the above (saved information.) see http://subversion.ardour.org/svn/ardour2/branches/2.0-ongoing/libs/midi++2/alsa_sequencer_midiport.cc particularly the get_state and set_state methods ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] ALSA autoconnect
On Wednesday, December 23, 2009, Jens M Andreasen wrote: Suppose you wanted a soft-synth to be instantly playable at startup (given the option: '--autoconnect') then what would be the ALSA functions for: 1) Saving the current live connection at exit (if any.) 2) Restoring the above (saved information.) /j I suppose that you mean the functions used by an alsa sequencer client program of any kind. I think that saving/restoring connections has more sense for players/recorders than softsynths. Using plain libasound API, the functions: snd_seq_connect_from() and snd_seq_connect_to() to make the conenctions, snd_seq_disconnect_to() and snd_seq_disconnect_from() to disconnect, you will need also snd_seq_parse_address() to transform the address in string form into a pair of client:port numbers. It is practical to save the address as a string name:port_number, instead of saving the client number, because the numbers are likely going to change the next time you start your programs, and the function snd_seq_parse_address() is able to translate the client names into the corresponding client numbers. For instance, this is taken from my VMPK current .config file: [Connections] InPort=KMidimon:0 OutPort=MidiSport 2x2:0 Regards, Pedro ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] ALSA autoconnect
It's quite easy with a jackd (via Qjackctl) setup; I'm not sure it's possible to do it reliably under ALSA. J.E.B. Suppose you wanted a soft-synth to be instantly playable at startup (given the option: '--autoconnect') then what would be the ALSA functions for: 1) Saving the current live connection at exit (if any.) 2) Restoring the above (saved information.) /j ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI
Nedko Arnaudov wrote: Hi Bob, thanks for commenting on LADI stuff The huge, major weak point that would prevent me from investing myself in LADI is the use of D-Bus which requires an extra, external layer in order to perform routing between objects on different buses. See my previous mail on the subject here: http://lalists.stanford.edu/lad/2009/11/0350.html From what Nedko has said on IRC, I believe LADISH has such a layer. D-Bus *can* span over multiple hosts. I've sent mail to this mailing list that explains how to do it and what needs to be improved: http://lalists.stanford.edu/lau/2009/11/0043.html see also: http://www.freedesktop.org/wiki/Software/DBusRemote (probably somewhat obsolete, check the timestamp and the missing link to gabriel site). I've adopted the gabriel project because it is possible to improve it as a mean to achieve multihost LADI studios in future: http://gabriel.sourceforge.net/ That said, there is no guarantee that ladish will use D-Bus for communication between daemon and apps. LASH got this mainly because of Juuso Alasuutari and because it was subject of his Summercode project. My aim with D-Bus + LASH was to use D-Bus for lashd - jack comunication and for lashd - control app communication. I agreed on using D-Bus for app - lashd communication because that simplified (yes it did) the LASH codebase. The use of D-Bus for app - ladishd IPC was risky and it took some time to fix bugs, but at the end we made it to work acceptably well. Also, there is no guarantee that ladish will use D-Bus for remote IPC. I have rough plan how to use D-Bus for multihost studios, but there is lot of work to do until 1.0 is reached. After 1.0 is reached, I will reconsider available options for the multihost capable ladish (that will be 2.0), I will decide and I'll provide finer milestones to acomplish this goal, in the same way as I did for 1.0. In summary, I plan to use D-Bus at least until ladish-1.0 is relased. I've seen lot of arguments against D-Bus and so far I din't find them valid for the goals I'm working for. If D-Bus gets proven as wrong choice for single hosts studio before the release of 1.0, I'll have to change it early. However I find such incident highly non-probable. Chances for remote D-Bus being not suitable are slightly higher and I'll reconsider D-Bus after ladish-1.0 release. Until then, D-Bus is the IPC technology that allows me to implement LADI features in fastest possible way and does not look as something that I'll abandon soon. I'm always open for constructive discussions, especially if they are in the scope of the LADI project. I'm open and glad for the feedback of early jackdbus and ladish adopters. Thanks for your explanation Nedko. It is clear to me that you see D-Bus as the best practical solution at the moment. But that you do not necessarily stick with it for always. You are open for discussion which is good in my opinion. Others seems to think that D-Bus is not the solution for an session handler for Linux audio. It doesn't have to be bad to have different opinions or different ways to solve a problem. Nedko, is LADI an project of your own, or are you willing to collaborate with other developers who might have interest in the project? Do I understand it right that characteristics of LADI are still open for discussion? Maybe it aint that bad to have two types of Session handlers for Linux. The LADI approach and another approach without D-Bus. It's not bad to have choice as user and maybe someone needs the features of LADI and others features of more minimal session handlers. Till now, LADI seems to be the only project that has reach an status so that it actually works and is useful for musicians. Other projects seems to be ideas on paper, nothing practical useful yet. As a user I'm hoping that LADI will become an success, cause at the end we really need an workable session handler. On the other hand I also hope that people like Fons, Bob, Torben and David are able to release an session handler without D-Bus. They have proven to have good ideas and programming skills. I think it will be good to have as much as consensus and especially collaboration as possible. It would be good if others join the LADI project I think. But I can't say which project goals are somewhat close to the LADI project goals. Someone said that Torbens ideas could be implemented or used in LADI in some way maybe. Then it would be good maybe, to have a good (privat) discussion between the developers (at least Nedko seems to say he stands open for that). And what about the other ideas? Is there a chance that David, Fons, Bob and others could find consensus between each other for a non D-Bus solution? I think everyone would agree that collaboration should be preferable here. Today there is only one choice and that is LADI, so I'll test that first and hope it works good enough for me
Re: [LAD] 802.11n sound card
On 12/23/2009 08:08 PM, Arnold Krille wrote: On Wednesday 23 December 2009 09:12:24 Patrick Shirkey wrote: On 12/23/2009 09:40 AM, Jörn Nettingsmeier wrote: Patrick Shirkey wrote: I had a thought that maybe the network sound card should not be using ethernet but instead wireless 802.11n. The ralink rt2870 chipset is well supported at full 300Mb/s on Linux and has open source drivers. I think this would open up a lot of opportunities with a wireless sound card. I'm not sure how many are on the market right now but I haven't heard of any yet so there is a big opportunity there to fill a gap. low latency audio over wireless is fundamentally impossible. it's a shared medium, pretty much like thicknet or any other hub or bus network. if two endpoints ever send at the same time (and they will), the packets will clash and trigger resends after a non-deterministic delay (so as to avoid endless re-clashing if two endpoints happen to be in sync). the only thing that would work over wireless is heavily-buffered media center stuff for consumers, because nobody cares if there's half a second delay between your pressing play and the start of the movie. So there's absolutely no way that a keyboard, pc, mixer, speaker set transferring data over 802.11n could be made to work? For example in a home studio setting... There is no way to make it work with guaranteed low latency. You need somewhat low latencies to play the keyboard to other music. And you need it guaranteed unless you always record xruns and gaps as part of your musical experience... And even then its wireless and using a frequency-range used by almost all other people around you. Just count the wireless networks in your flat provided you live in a flat with other people living upstairs/downstairs/next to you. And then try to get a fast, non-interrupted stream (latency about 20ms or shorter for real playing). So the issue is with other streams being picked up by the receiver which affects latency by increasing collisions? Would this still be a problem on a secured connection? Surely the receiver would ignore all data that is not being transmitted over the secured access point? Does anyone have an idea of how to work out the actual latency for a wifi packet at 300Mb/s? If we are talking about a studio setup with devices no further than 2 meters distance from each other that should aloow sub 20ms send/receive. The bottle neck appears to be the chip and the code that manages the transmit/receive process. Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] mx44...2?
Mx44 bumped to version 2 http://web.comhem.se/luna/ New in Mx44.2: Copy/paste of individual oscillators. Choice of temperament (Natural, Mean, Well- and Even tempered.) Optional auto-connect to jackd, optional patch location OSS deleted as well as numerous other bugs, thanks to James Morris who contributed heavily to this release. Release at dawn on Christmas Evenings Day? Yes :-) Consider it done! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jcgui-0.4 initial release
Thanks Alex Glad to hear you like it, . . How far you are with the openoctave project, do you still work on the removal of the KDE 3 dependences ? I would love to check out your Open Octave Verb, the screen shot looks real nice. hermann Am Mittwoch, den 23.12.2009, 15:28 + schrieb alex stone: Hermann, nice work, and thanks. Runs fine here on Gentoo 64bit. Alex. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
