Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7501 discussions

by Nedko Arnaudov

New version of Simple Sine Generator is available. Simple Sine Generator is very simple instrument/generator plugin with midi in and audio out. It expected to be useful for testing LV2 hosts and as base for writing your own plugins. It is written in plain C. = What is new = Main change is switch to event port LV2 extension. LV2 URI is changed and installation directory is changed too. So you can have both older midi port variant and newer even port ssg installed simultaneously. Also, bug in Makefile is fixed. If with earlier version you got error on compilation because of missing fftw or dynparam libraries, now it should be fine. Also, there is fix of a pitch bug (wrong octave). I'd like to thank Andreas Kusterer for switching ssg to even port extension. Simple Sine Generator has trac homepage now: http://nedko.arnaudov.name/soft/ssg/trac = Download = http://nedko.arnaudov.name/soft/ssg/ssg-1.13.tar.bz2 http://nedko.arnaudov.name/soft/ssg/ssg-1.13.tar.bz2.sig -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>

17 years, 1 month

[ANN] ll-plugins 0.2.0

by Lars Luthman

ll-plugins is a small collection of LV2 plugins and a host that runs them. This is the first release. In order to build ll-plugins you need to have the following packages installed: cairomm >= 1.2.4 gtkmm >= 2.8.8 libjack >= 0.109.0 liblash >= 0.5.1 lv2-c++-tools >= 1.0.0 libsndfile >= 1.0.16 libsamplerate >= 0.1.2 You can download the latest released version of ll-plugins from http://ll-plugins.nongnu.org You can also get the latest development code from the Git repository using this command: git clone git://git.sv.gnu.org/ll-plugins.git Beware that the development code may not work or even compile. THE PLUGINS =========== All plugins are installed in separate LV2 bundles (except the ones that are closely related, like the math-constant plugins or the mono and stereo versions of the peak meter). The GUIs, for the plugins that have GUIs, are installed in bundles of their own to make it easier for packagers to put them in separate binary packages to avoid Gtk dependencies for the plugins themselves. The plugins are reasonably simple and could be used as examples or starting points for hackers who want to write LV2 plugins based on the frameworks in the lv2-c++-tools package. There are synths, event processors, simple audio and control manipulators and GUI-based plugins. BASIC ARPEGGIATOR ================= This plugin is just what it says. It takes MIDI event input and writes MIDI event output in the form of an arpeggio over the held keys in the input. You can control the speed of the arpeggio and the direction (up or down). CONTROL2MIDI ============ A plugin that converts a LV2 control port value to MIDI CC events. You can set the CC number and the expected range of the input value. KLAVIATUR ========= A MIDI keyboard. You can use it to send pitchbend events, CC events and of course notes, using mouse or keyboard. Handy when you want to test a synth patch but don't have a real keyboard nearby. Klaviatur has a Gtk GUI that you use to control it. MATH-CONSTANTS ============== A set of plugins that output constant control parameters for mathematical constants defined in the C header <math.h>. MATH-FUNCTIONS ============== A set of plugins wrapping most of the functions in the C header <math.h> (sin(), cos(), exp(), modf() etc). All are available as both audio rate and control rate functions. PEAK METER ========== A decaying peak meter that shows the peak level of the input signal. There is a mono and a stereo version. Both have Gtk GUIs. RUDOLF 556 ========== A simple drum machine with six separate drum voices - two bass drums, two snares and two hihats. The different voices are mapped to C, D, E, F, G and A in all octaves, and every voice has three control parameters (length, hardness and volume). This plugin has a Gtk GUI that you can use to control the parameters. SINESHAPER ========== An LV2 version of the Sineshaper synth - two sine oscillators fed through two sine waveshapers in series, with a bunch of parameters to control them. This plugin has a Gtk GUI too. THE HOST ======== The host that comes with this package is called Elven (Experimental LV2 Execution ENvironment). It is pretty slow and I don't really recommend it. If you can use another host, do that. --ll

17 years, 1 month

SoundMAX AD1988A/AD1988B

by Jens M Andreasen

Hi! I have recently done some window-shopping to get a grip on what is out there these days (should the temptation to spend even more money on tech become irresistable ...) Anyways, this chip: http://www.analog.com/UploadedFiles/Data_Sheets/AD1988A_1988B.pdf#xml=http:… .. appears to be quite popular, has 10 (ten!) channels out at 24/196 plus a healthy 6 channels in. I wonder, do any vendors really connect all of this to any real physical ports? --

17 years, 1 month

Non-DAW's Session Handling Requirements

by malnourite＠gmail.com

http://karma.darktech.org/~male/lash_requirements.html _____________________________ ______ __ _ _ -+--- Overview - - - The Non-DAW comprises a modular system. It would be convenient for the author and the users alike if the state of Non-DAW's components and other, entirely separate, programs could be managed together as a coherent whole. The LASH system appears, at first glance, to support this kind of arrangement. However, the current LASH API is overly complex and lacking in what this author considers to be a basic level of functional maturity. It is this confusion, I believe, which has resulted in the poor adoption of LASH and its subsequent stagnation. ______ __ _ _ -+--- Basic Concerns - - - Non-DAW, and other complex programs with large state which cannot be held in RAM all at once, require a few things that LASH doesn't currently provide. These needs include the following: 1. The need to know the LASH project path the moment it first joins the LASH session at startup. If this were so it could start a new Non-DAW project under the LASH project path and new captures would go in their right place without any intervention by the user. To clarify: there must be no time when Non-DAW is connected to LASH without knowledge of the path to the current LASH project directory. 2. The need to be informed of, or else be able to query at any time, the LASH project name. If the LASH project path and the LASH project name weren't different, we could get away with scanning the path for the name, but this is unfortunately not the case. Additionally, the following would be required in order to fully integrate with LASH (transparently to the user). 1. Ability to initiate new projects, choosing among a list of previously recorded templates. 2. Ability to save the current project as a template. 3. Ability to initiate a save of the entire LASH project. 4. Ability to choose from a list of LASH projects to load. Some of the above are already possible to some extent with the current API, but complicated greatly by the artificial division of the API into client and control portions. Non-DAW and Non-Sequencer have the ability to change to a new project/song without restarting, but LASH makes no use of this--always restarting instances of these programs instead of reusing them. Of course, Non-DAW and Non-Sequencer have extremely short startup times compared to other programs in their class, but still, I would like to avoid the distraction of many windows opening and closing at LASH project change time--it reflects poorly on my and any other programs which can change songs without crashing. I would also like to see the preferred behavior of new/save/load operations in all clients specified by LASH so as to avoid confusion and potential data loss. Should any LASH client be permitted to save or load to/from disk /it's own state/ without informing LASH? This may seem harmless when the program state consists of a single file--as it is assumed that a copy of that file will be saved by the program in the LASH project directory whenever a LASH save is next performed. But now the user has two (differing) copies of his file--and he isn't sure which one he really edited--or where it is on disk. The problem becomes even more serious when the program state includes a directory filled with gigabytes of audio sources... Is it really advisable for LASH clients to operate on their state, which is supposedly under the control of LASH, as if it was theirs alone--without informing LASH of their activities? I don't necessarily know the answer to this question, but I do know that LASH needs to make a recommendation of some kind regarding the expected behavior--whatever it may be. ______ __ _ _ -+--- Additional Thoughts - - - There are also many things which LASH /could/ do to enhance the integration experience, but doesn't. These include, but are by no means limited to, the following: * Templating and layering functionality. * Project grouping (eg. all songs for an album) for easy management of hundreds of projects. Please use subdirectories and/or symlinks for this and not some XML junk. * Global Undo/Redo functionality (simply sends a message to all clients asking them to undo/redo and possibly providing feedback), additionally, we can envision storing state diffs on disk for clients with no native undo capability--something akin having the state in a git repo could be used, reloading a reconstruction of prior state upon an 'undo' request)--this is only viable if LASH can reuse program instances. * Looser integration with/no direct dependance on JACK. Some of these have been mentioned before and I've omitted many potential improvements and design changes which I consider less important. -- May 15 2008, John Moore Liles

17 years, 1 month

JACK transport position and OSC timetag

by Olivier Guilyardi

Hi, is there a way to compute an absolute timetag from the jack position in order to send timestamped OSC messages, from the jack process callback? Regards, -- Olivier

17 years, 1 month

ppc audio distro?

by Justin Smith

I just got an ibook g4. Is anyone out there using a ppc distro for audio? Is there an audio-specific ppc distro?

17 years, 1 month

LV2 port groups

by Fons Adriaensen

Is there any good reason why the B-format port groups refer to the 2nd order horizontal components as R and S ? -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa.

17 years, 1 month

completely [ot] - compilation help

by Julien Claassen

Hello folks! I'm soory for posting here, but I hope someone can help me. I'm just compiling a bit of code and gcc gives a strange error, which Ican't fix. Code snippet: [...] if (ioctl (vcsa_fd, KBD_SNIFF_SET, &set) < 0) { sbl_log ("no kernel support for keyboard sniffing\n"); kbd_sniffing = 0; return 0; } else { ... } /* end of snipet */ the reproduceable compiler error says something about the if-statement: kbd.h:96: error: expected ')' before '[' token It does the same for two other ioctl statements, one incuded in an if, the other in an assignment like: value = ioctl (...); My gcc is: gcc 4.2.3 (Debian 4.2.3-3) Please: can someone help me here? It's so frustrating... Kindest regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

17 years, 1 month

FW: [piksel] The future of videojack ?

by Ivica Ico Bukvic

> On Sat, May 3, 2008 03:27, salsaman(a)xs4all.nl wrote: > > Hi all, > > after some long and protracted discussion with the jack developers on > > their mailing list, I have come to the conclusion that they will > probably > > never accept the videojack patches into the main jack trunk. I also made > > some suggestions to make jack startup easier for non-technical users, > and > > these were rejected. The attitude seems to be that the goal of jack is > > simply to make a high quality server for audio, and if this means adding > > complexity to the startup, requiring kernel patches, etc. then so be it. > > > > Some of the jack developers suggested to me that I look into using > > pulseaudio (http://www.pulseaudio.org/) since it seems more suited to my > > needs. I haven't had a chance to look into it deeply yet, but it looks > > like an interesting project. > > > > As a result of all this, here is what I suggest: > > > > - we maintain our own fork of jack based on the current videojack code > and > > clients and backport any fixes from the main jack trunk as well as we > can. > > For this it would be nice to have a CVS/SVN set up. > > > > - use the vjack-devel mailing list from BEK to discuss development of > this > > branch > > > > - look into pulseaudio, and see if it might be possible to make a > > "pulsevideo" - if it seems possible and wise, approach the pulseaudio > > developers and see if they are more open to accepting non-audio patches. > > > > - discuss the pros and cons of writing something like videojack from > > scratch - basically, what is needed - a server that provides timing and > > calls callbacks and uses shared memory to pass framebuffers; client code > > which connects to the server and sets up the callbacks; control > interfaces > > to list, connect, and disconnect the clients > > - or maybe it's better to make a stripped down version of vjack that > only > > handles video ? > > - think about whether we want to be able to synch with audio from jack > > and/or pulseaudio. > > > > Please discuss... > > > > > > Salsaman. > > http://lives.sf.net > > > > > > > > _______________________________________________ > > piksel mailing list > > piksel(a)bek.no > > https://www.bek.no/mailman/listinfo/piksel > > http://www.piksel.no > > > > > > Well, since nobody else seems to have an opinion on this, I guess I will > go ahead with what I suggested. > > Here is what I plan to do: > > 1) register a project on sourceforge (vjack.sf.net ?) > 2) check the current videojack code in to subversion; set up basic web > page for vjack (this can later be pointed to jackvideo.org) > > 3) check the changelog for jack and backport any important fixes > 4) trim down the codebase - remove all drivers except the "dummy" driver > 5) change all occurances of "jack" to "vjack", eg in function names and > enums; create libvjack > 6) update all clients "jack" -> "vjack" > 7) make the changes necessary for vjack - make rate a float; change > default rc file to ~/.vjackdrc and allow an enviroment parameter to > override the default location; change default server name from "default" > to "video0"; allow vjack_connect, vjack_disconnect and vjack_lsp to > specify a server name > 8) create basic documentation and HOWTOs > > Since this is quite a lot to do, are there any volunteers to help with > this ? > > > > Salsaman. > http://lives.sf.net > > > > -- > "We are called to be architects of the future, not its victims." > - R. Buckminster Fuller > > _______________________________________________ > piksel mailing list > piksel(a)bek.no > https://www.bek.no/mailman/listinfo/piksel > http://www.piksel.no Although I obviously do not know the whole story, this to me is highly disturbing. Having video sync (like MIDI sync that is apparently being worked on) within Jack would allow us to do professional sample-accurate multimedia production. The alternative suggested above simply reinforces the problem JACK in and of itself faces in respect to myriad of other (mostly subpar) solutions. Given that we have a lot of contributors in our midst who apparently are unable to find common language (so they go on to reinvent the wheel with their own often incomplete implementation), it would be nice to see LAD community (especially considering as small as it is) not propagate this unfortunate predicament. Once again, please note that the aforesaid is my gut-reaction as I obviously am not familiar with the innards of this matter. Best wishes, ico

17 years, 1 month

Re: [LAD] [Jack-Devel] [piksel] Re : The future of videojack ?

by salsaman＠xs4all.nl

On Wed, May 7, 2008 22:04, Stéphane Letz wrote: > > Le 7 mai 08 à 21:37, Juuso Alasuutari a écrit : > >> Stéphane Letz wrote: >>> Video in jack1 won't happen because of several reasons that can be >>> explained again: we want to fix and release jack1 soon and video >>> in jack is a too big change to be integrated in the current state >>> of the proposed patch. >>> The future of jack is now jack2, based on the jackdmp new >>> implementation (http://www.grame.fr/~letz/jackdmp.html). A lot of >>> work has already been done in this code base that is now API >>> equivalent to jack2. New features are already worked on like the >>> DBUS based control (developed in the "control" branch) and NetJack >>> rework (developed in the "network" branch). >>> I think a combined "video + audio in a unique server" approach is >>> perfectly possible: this would require having 2 separated graph >>> for audio and video running at their own rate. Video and audio >>> would be done in different callbacks and thus handled in different >>> threads (probably running at 2 different priorities so that audio >>> can "interrupt" video). Obviously doing that the right way would >>> require a bit of work, but is probably much easier to design and >>> implement in jackd2 codebase. >>> Thus I think a better overall approach to avoid "video jack fork" >>> is to work in this direction, possibly by implementing video jack >>> with the "separated server" idea first (since is is easier to >>> implement). This could be started right away in a jack2 branch. >> >> I'll throw in my 2 Euro cents. >> >> If the VideoJACK crowd feels that JACK2 development is taking too >> slow and decide to continue with their fork, may I suggest that we >> all still discuss and draft a proper video API together? If a fork >> happens out of practical reasons, it would be best to make sure >> that switching video software to use JACK2 later on will be as >> painless as possible. >> >> Technical issues aside, I wish that those affiliated with VideoJACK >> do not feel that their needs are neglected by the JACK developers. >> I hope that the recent discussion has proved that people in this >> camp are willing to improve JACK in this respect. Perhaps we could >> move on and try to find more common ground? >> >> Juuso > > Yes sure. > > Where is the latest state of the video patch for jack? I can have a > look and see how easy/difficult it would be to implement that in a > jackdmp/jack2 branch. > > Stephane > > _______________________________________________ > piksel mailing list > piksel(a)bek.no > https://www.bek.no/mailman/listinfo/piksel > http://www.piksel.no > > Please forward to the LAD mailing list, since I am not subscribed there, and unable to post. I will just describe briefly the current API. It would be nice everybody would agree that this is OK, otherwise please can we resolve this quickly - the project is going slowly enough as it is. ---------------------------------------------------------- The videojack patch adds a new port type - video. #define JACK_VIDEO_PORT_TYPE 2 There is no mixing function for video, since there are dozens or maybe hundreds of different ways to mix two or more video frames together; all mixing is done by a host application. Therefore each video buffer can have only one source, but may have multiple sinks. The size of the video buffer is initially set to 0x0, and the colorspace is set to the default (JACK_VIDEO_COLORSPACE_RGBA32). The source client only may set the frame size at any time, and may also change the colorspace. Although only RGBA32 is supported officially, other colorspaces may be used in private networks. The source client sets width and height using: int jack_video_set_width_and_height (jack_client_t *client, jack_port_t *port, uint32_t width, uint32_t height) and may set the colorspace with: int jack_video_set_colorspace(jack_client_t *client, jack_port_t *port, jack_video_colorspace_t cspace) These functions may only be called after the client is activated by the source. The functions also set the buffer size to 4*width*height. Likewise, there are the functions: uint32_t jack_video_get_width(jack_client_t *client, jack_port_t *port) uint32_t jack_video_get_height(jack_client_t *client, jack_port_t *port) jack_video_colorspace_t jack_video_get_colorspace(jack_client_t *client, jack_port_t *port) A client may set callbacks for these: int jack_set_video_colorspace_callback (jack_client_t *client, JackVideoColorspaceCallback video_colorspace_callback, void *arg); int jack_set_video_size_callback (jack_client_t *client, JackVideoSizeCallback video_size_callback, void *arg); Although probably the client would only get a buffer size change message, since jack can only send one message per change (seems to be a limitation in jackd). There is also a convenience function: void* jack_video_get_framebuffer(jack_port_t* video_port) which just does: return jack_port_get_buffer (video_port, 1); And that's it ! This is enough to get video working in jack. There are a couple of changes I plan to make, which are just nice-to- have: - make rate a float (for the video clock) - use an environment variable to define the location of ~/.jackdrc (this will go away if video and audio clocks can be combined in one server) Also I will patch jack_connect, jack_disconnect, and jack_lsp to take a server name. This is necessary right now if running two servers, video and audio. But it seems like a good idea to keep it in anyway. And as suggested, jack_set_video_process_callback() will just call jack_set_process_callback() (for now). Later it could link to a video clock in a combined server. There was a further suggestion that the input client can set a "frame count", which can be read by the output clients. This should also be feasable. -------------------------------------------------------- The current code is at: http://bekstation.bek.no/piksel/pikseldev/jack-vjack5.tar.bz2 The startup parameters I use are: /usr/bin/jackd -p 10 -t 40 -d dummy -r 25 -p 1 -P 0 -C 0 Note the last -p 1 is necessary, otherwise you get a floating point exception. All other parameters can be adjusted as necessary. There are also various clients - jack_video_test_generator and jack_video_output are shipped by default. On the piksel site there is a hacked version of camorama: http://bekstation.bek.no/piksel/pikseldev/camorama-vjack.tar.bz2 and ekiga: http://www.xs4all.nl/~salsaman/ekiga-2.0.12-hacked-for-vjack.tar.bz2 LiVES also supports vjack in an vjack out. You must compile it with --enable-vjack. The vjack output client can be selected in Preferences/Playback. The input client (generator) must be bound to an effect key (VJ/Realtime effect mapping), and then activated. Regards, Salsaman. _______________________________________________ Jack-Devel mailing list Jack-Devel(a)lists.jackaudio.org http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

17 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev