Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

by Kris Calabio

I want to learn how to program with JACK. I found this tutorial: http://dis-dot-dat.net/index.cgi?item=/jacktuts/starting/ linked from this page ( http://jackaudio.org/documentation ). I noticed that the tutorial has some broken links. Is this still a good resource to learn from? Or are there any better ones out there? Any suggestions will be much appreciated. Thanks, Kris

13 years, 8 months

Laborejo Release 0.1 Announcement

by Nils

Laborejo, Esperanto for "Workshop", is used to craft music through notation. It is a Lilypond GUI frontend, a MIDI creator and finally a tool collection to inspire and help you compose. It works by reducing music-redundancy and by seperating layout and data. Don't worry about the layout, just concentrate on the music. Screenshot (Laborejo and Lilypond, side by side): http://www.laborejo.org/images/screenshots/2012-01-31-223820_3840x1080_scro… This is the first release, version number 0.1 Download: https://github.com/nilsgey/Laborejo/tarball/0.1 Dependencies: http://www.laborejo.org/documentation There are too many features to mention them all and too many missing features and bugs to warn you. Most important known problems: * This is Alpha Grade Software. Don't use for long-term work. However, the produced midis and PDFs will last forever. * Performance can get bad very quickly if you use Containers. * There is no built-in sophisticated midi player/jack midi output yet. You have to export midi files. * Documentation is nearly non-existent. Have fun, it would be nice to hear from you! Nils http://www.laborejo.org (All kinds of crazy social web services are linked there!)

13 years, 8 months

[ANN] Qtractor 0.5.4 - Echo Victor shouts out!

by Rui Nuno Capela

Howdy, There's no victory over anything whatsoever. Read it again, it's just a codename. If that serves anything at all, to my own defense that is, Qtractor is still a pet project hobby of mine, as all things in Linux audio world for that matter. There's been too many saying and comparing Ardour vs. Qtractor. I'm seeing if often said in too many sentences lately and, believe me, I cannot stand comfortable with that saying no more. So here it goes: Ardour is a full fledged, pro-level DAW and, for crying out loud on its own, the flagship of the free/open-source pro-audio fleet and movement, not only Linux anymore nowadays. On the other hand, Qtractor is 'a sequencer' (hinted by its own subtitle, in case you didn't notice) with a twist and a few of a DAW features. And it strictly runs on the Linux platform only and most important yet, it has been targeted to a (re)creational personal home-studio audience ever since. Heard about the 'techno-boy bedroom' (with a guitar) folk? Well, that's exactly what it is, from day zero. Hope you all get the picture ;) Enough whining. Qtractor 0.5.4 (echo victor) is out and is shouting out loud! Release highlights: * Panic command button (NEW) * Improved audio/MIDI file resource management (NEW) * MIDI SysEx for instrument plugins (NEW) * MIDI Controller auto-hook option (NEW) * MIDI Tools resize ramp (NEW) * Revised plugin search directory paths (FIX) * MIDI zero-duration note-on/off queueing (FIX) * Audio linked-clips looping (FIX) Website: http://qtractor.sourceforge.net Project page: http://sourceforge.net/projects/qtractor Downloads: - source tarball: http://downloads.sourceforge.net/qtractor/qtractor-0.5.4.tar.gz - source package (openSUSE 12.1): http://downloads.sourceforge.net/qtractor/qtractor-0.5.4-3.rncbc.suse121.sr… - binary packages (openSUSE 12.1): http://downloads.sourceforge.net/qtractor/qtractor-0.5.4-3.rncbc.suse121.i5… http://downloads.sourceforge.net/qtractor/qtractor-0.5.4-3.rncbc.suse121.x8… - long time ago, far far away: user manual: http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf Weblog (upstream support): http://www.rncbc.org License: Qtractor is free, open-source software, distributed under the terms of the GNU General Public License (GPL) version 2 or later. Change-log: - Direct access plugin/insert parameter changing tool-tip added. - A Transport/Panic action enters the scene, in a nostalgic attempt to emulate the all-MIDI-track-shut-off command of those drop-dead and primordial MIDI sequencers of all time. Now finally a keyboard shortcut and mouse click-away ;) - MIDI editor command redo/undo adjustment now effective on all other channel events besides notes, which overlap at the same event time. - A new File/Unlink menu action is now made available from the MIDI clip editor (aka. piano-roll) for detaching the current linked/ref-counted MIDI clip into a new auto-incremented SMF filename. - Some audio/MIDI content/media-file resource management is entering the scene, taking care of some file-system house-keeping, this gets evident on unsaved/dead recorded files being automaticaly removed from the file-system, on session close. - Killed the old and entirely deprecated LV2 Save/Restore and Persist feature/extensions support. - Auto-monitored MIDI events are now merged/queued correctly into the instrument plugin playback queue, avoiding sudden crashes, hopefully. - Awesome patch from Albert Graef, thanks, which makes most MIDI SysEx to get through MIDI instrument plugins at last; applies to DSSI and LV2 plugins only. - LV2 URID map/unmap feature support added. - Plugin parameter value redo/undo command aliasing fix. - Double-clicking in plugin list item now show/activates the plugin's editor window (was toggling visibility/activation). - Plugin path settings have been fixed again, with special regards to an effective LV2_PATH environment variable settlement. - Session properties dialog now asks to create a new session directory if the given one does not currently exist. - MIDI note names and their respective octave numbers are now compliant with the ISO standard where middle C (60) is now C4 (was C3). - Fixed audible glitch/pop at the beginning of an audio clip with long quadratic or cubic shaped fade-in (reported by Lougi Verona, thanks). - MIDI Controller Auto-Hook patch by Alessandro Preziosi, thanks. - Make sure all MIDI note-off are always queued after their respective note-on events when buffering for MIDI input of instrument plugins, event though for zero duration MIDI note events (hopefully fixing the hanging notes bug #3476124, as reported by Albert Graef, thanks). - LV2 MIDI-fx plugin support has been repaired. - Single-track clip selection logic corrected again, fixing multi-clip selection drag/move across an odd number of distinct tracks (after a bug report by Louigi Verona, on linux-audio-dev, thanks). - MMC Locate time-code hour bit-field fix; MMC Locate now also on loop turnarounds (patches by Albert Graef, thanks). - Looping across multiple linked/ref-counted audio clips was incredibly broken with complete out-of-sync playback. Hopefully fixed now, with auto-unlinking/cloning all the affected audio clip buffers. - Audio clip overlapping detection off-by-one(-frame) fix. - MIDI Tools/Resize value ramp mode has been added (mocking the 'resize to range' feature request #3467894, by Daniel MacDonald aka. danboid). Enjoy && Have fun! -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

13 years, 8 months

Re: [LAD] [LAU] Music made with Linux: Airship - A 16bit Soundtrack Theme

by Carlos sanchiavedraz

2012/2/29 Kevin Thoma <kevin.thoma88(a)gmail.com> > Hi there, > > really liking the piece, great job! And having just played one of those > RPGs for the first time in ages (and I do remember them from my childhood > days as well...), I can attest to the fact that it would them nicely. ;) > I agree that taking the drums out for one of the quieter parts would have > made for some nice contrast, but yeah, that's not a must. > > Best Wishes > Kevin > > > On Wed, Feb 29, 2012 at 6:30 PM, Nils <list(a)nilsgey.de> wrote: > >> Hello list, >> >> I would like to share a piece I've just finished. >> The original blog entry is here, but for your convenience I'll include a >> copy into this mail. >> Feel free to use any channel you want if you would like to comment on it. >> http://www.nilsgey.de/2012/02/29/airship-theme/ >> >> Airship - A 16bit Soundtrack Theme >> direct download: http://www.nilsgey.de/uploads/NilsGey-AirshipTheme.mp3 >> >> I have finished my first just-for-fun composition since a very long time >> ago. It is a game-soundtrack like piece I named “Airship”. I can imagine >> this in a Japanese 90’s RPG from the SNES or Sega Genesis/MegaDrive era. >> >> Software used: Laborejo composition and midi generation, Fluidsynth for >> midi to wave rendering and Ardour for the fadeout :) . >> >> I used an .sf2 called Setzers SPC which I have downloaded here. I am not >> sure about the soundfonts legal status so I am careful and release the >> Airship Theme not as a free piece but just as: Listen to it freely, share >> and redistribute it but don’t use it in any work, derived or original, or >> as part of a game or video etc. Don’t do anything commercial with it and >> don’t change the mp3 tags. If you find a named, matching License to this >> description feel free to use that instead. >> >> I would be very happy if you leave a comment or click this blogs “Like” >> button. >> >> >> Greetings, >> >> Nils >> http://www.nilsgey.de >> http://www.laborejo.org >> _______________________________________________ >> Linux-audio-user mailing list >> Linux-audio-user(a)lists.linuxaudio.org >> http://lists.linuxaudio.org/listinfo/linux-audio-user >> > > > _______________________________________________ > Linux-audio-user mailing list > Linux-audio-user(a)lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-user > > Hi, I concur with some said already; it reminds a bit of some soundtrack for a game and maybe, at 1:00 min and at 4:30 aprox., would be nice to have a quiet part as a middle section to rise then up as an anthem. Also would be advisable some processing (Delay, Reverb) on the mix to make the sound a more realistic, to mitigate the rude MIDI sound, and as if recorded in some space, a large hall i.e. Nice music, Thanks for sharing, Nils -- Carlos sanchiavedraz * Musix GNU+Linux http://www.musix.es

13 years, 8 months

Re: [LAD] ALAC codec being added to libsndfile

by Erik de Castro Lopo

Georg Holzmann wrote: > Hallo! > > > The only real problem I've had doing it is finding time to work > > on it. Fortunately I am pretty sure I will find time to work on > > this between xmas and new year. > > Thanks for the answer! > If you need any testing or something else let me know! Hi Georg, Support for 16 bit ALAC is in Git at: https://github.com/erikd/libsndfile Support for other bit widths will be added in the near future once I know the 16 bit stuff is working. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

13 years, 8 months

OSC sequencer idea (was: Qtractor 0.5.4 - Echo Victor shouts out!)

by Stephen Sinclair

It seems this debate is how to represent OSC messages in a sequencer. I've thought about this before, and the idea I always had in my head was something tracker-like, where you would assign columns (or rows..) to a message path, and specify whether the arguments are ints, floats, etc. For each argument the column would contain subcolumns with fields allowing editing of these values. Any row that is all "nil" would mean "do not send a message." The editor might allow a special column type called "note" which is represented on-screen as a note name (A#3 or whatever) but sends out the value as an integer or float. Alternatively the editor could be told the min/max values of the subcolumn and represent it as horizontal bars or a line plot, etc. I even started working on such a thing once, with the intention of controlling sequences for custom synths written in e.g. Chuck or PureData. However, I never got far with it as I had other things to do. In any case, in this paradigm, the user would define a patch in Pd (or....) which accepts certain control or trigger messages, and therefore the sequencer would need to be told what messages to send it. No need to "standardize" the messages for any particular representation, since it would be different for each patch anyways. (The "sequence + patch" would be considered together as the music file.) What I like about this is that it would allow a user to use whatever program he/she wants for sound synthesis, but have keep a consistent sequencer interface. You could even use multiple back-ends for sound synthesis in the same track. p.s. thanks Jonathan for bringing up libmapper. For those who don't know, libmapper is an attempt to create a "glue" layer for OSC-supporting programs. Instead of standardizing on a set of messages, the idea is to instruct sending programs to translate their messages into the format required by the receiver, including any data transformation (scaling, etc). This allows programs to use any message names they want, keeping the usefulness of readable, program-specific semantic naming schemes, while still being able to connect to each other. Still under heavy development, but it's quite functional, web site is at http://libmapper.org Steve On Sun, Mar 4, 2012 at 4:27 PM, Albert Graef <Dr.Graef(a)t-online.de> wrote: > On 03/04/2012 06:32 PM, David Robillard wrote: >> >> What do you mean by "pick the OSC addresses that I want"? > > > I mean those symbols with the slashes that are the first part of any atomic > OSC message like /foo/bar 4711.0. Usually such a symbol would denote the > particular control that the value applies to. When using OSC as input to or > output from automation, obviously I'd have to specify which OSC addresses I > want to be mapped to which automation parameter. > > However, I'd actually prefer a kind of separate OSC track which would be > connected to OSC inputs and outputs and listens for all OSC messages on its > OSC inputs, no matter what the addresses are. So (an ASCII representation > of) the contents of such a track might look like > > # delta OSC addr value > 0 /foo/bar 0.78 > 10 /reverb1/wet 0.3 > 5 /foo/bar 0.66 > etc. etc. > > By these means the OSC track would just record any messages that it receives > on its inputs, and I might then map them to the appropriate automation > parameters on other (audio and MIDI) tracks in the DAW, or just have them > played back via the OSC outputs assigned to the track, in order to drive > some other application like Pd. > > Dave, will you be at LAC in April? I'd really like to discuss this in more > detail with you, but it's much easier to do this in a room together and with > a whiteboard and a data projector within reach. ;-) If there's enough > interest, maybe we could do a "control beyond midi" brainstorming session at > LAC? Maybe Rui wants to join us there, and I know that some guys at CCRMA > are also interested in this. I guess that the organizers can allocate us a > time slot and a room with the necessary equipment if we just ask for it. > > Albert > > P.S.: Rui, apologies for hitchhiking your thread. I hope that you will > forgive me over a glass of good Californian wine. ;-) > > > -- > Dr. Albert Gr"af > Dept. of Music-Informatics, University of Mainz, Germany > Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de > WWW: http://www.musikinformatik.uni-mainz.de/ag > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev

13 years, 8 months

preset saving in sessions

by parched2099

With the advent of NSM, there's a better chance than ever for autoloaded sessions when working. One of the challenges of autoswitching between sessions is loading presets for that session. In, for example LV2rack, it starts, but presets have to be loaded manually, after it gets going. Is there a mechanism for LV2rack, and other standalone plugin hosts, to have a preset automatically load with the selected preset for a session, when that session is selected? An example is lv2rack with the IR lv2 plugin, which i've been testing in NSM. LV2rack comes up ok, but the preset i've built for a specific session doesn't automatically load. I assume this is the case when using something like LV2rack in other session managers too. Where would a call for an autoloaded session saved preset come from? The session manager, or LV2rack itself?

13 years, 8 months

Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out! (Emanuel

by Jeff McClintock

> The chance for MIDI to improve seems very low, due to its technical > limits. HD-Protocol MIDI is coming, albeit with painfully slow progress. Best Regards, Jeff

13 years, 8 months

[ANN] Non DAW and Non Mixer 1.1.0 (now with NSM)

by J. Liles

Greetings, I'm pleased to announce the release of Non-DAW and Non-Mixer version 1.1.0. It's been a while since the last release. But, I assure you, the project is still alive and well. This release includes a number of fixes and some minor improvements to the build system. The big changes are: * Enhancements to the spatialization controls (which are automatically provided for Ambisonics plugins). * Support for the Non Session Manager. * Enhancements to Control Sequences, OSC control signals can be sent from Non-DAW to Non-Mixer. These connections will be preserved in the session. * Non-Mixer accepts input for all Module/Plugin controls via OSC. * Non-Mixer can now import and export individual strips (including the chain of modules and all their parameters!) This allows a workflow on a higher level than presets. * Updated visual styles for both Non-Mixer and Non-DAW. The 'Flat' style has been greatly improved. * New knob styles for Non-Mixer and knob style is a configuration option rather than requiring editing the source. * New icons in an assortment of sizes. Additionally, Non now supports a robust new session management protocol called NSM. A session management daemon is provided along with a graphical interface called Non-Session-Manager. NSM represents a significant leap forward for session management in Linux audio. :: History of NSM Way back in 2008, I became frustrated with the state of the art of session management on Linux (a situation which has improved only incrementally since that time). I ditched support for LASH, wrote a lengthy post about Non-DAW's session management requirements to the LAD mailing list, and started managing my sessions with shell scripts and jack_snapshot. This eventually evolved into a session manager written in Unix shell and using Unix FIFOs and regular files for client control/communication. This system of session management was tentatively called NASH (Non Audio Session Handler) and was never released. In 2010, shortly after the release of Non-Mixer, I devised a prototype version of the NSM OSC API and have been using it, still unreleased and in prototype form, since then. The 2010 implementation did not have a user interface and was controlled via shell scripts using the `send_osc` command included in the distribution. Then, in 2012 (4 years later!), I was contacted by an enthusiastic power-user regarding implementing OSC support in Non-Mixer. Since NSM uses OSC for server<->client communication, I already had much of the OSC work done and figured I might as well release it--and, while I was at it, NSM. I then endeavored to simplify and document the NSM API, discussing it at length with, and taking many suggestions from, Nedko Arnaudov, the LADISH author. After implementing the Non-Session-Manager FLTK GUI to control the session management daemon, a new release became inevitable. :: Bullet Points for NSM: * Extremely fast and responsive control mechanism and user interface. * The only dependency for clients and server is an OSC library (I use liblo). * Smart clients are able to switch projects without restarting. * Clients can provide real-time status feedback to the server, and therefor the user. * The server stores all session data in per-session directories under a configurable session root. * Clients are forbidden to save or open files outside of the per-session directory. * The server provides simple template support in the form of whole-session duplication. * The Session management daemon is fully controllable via OSC. * Strict user interface guidelines for a uniform and predictable experience. * The abstract session management API has no architectural requirement for JACK, Xorg or any other subsystem (other than UDP networking). This means that both headless daemons and programs which are not JACK clients can be managed together in the same session. * A single session can be distributed across multiple machines on a network. * Multiple, independent, sessions can be opened on one machine at the same time. :: More About the NSM API The latest NSM API documentation can be found at: http://non.tuxfamily.org/nsm/API.html NSM is included in the Non-DAW/Non-Mixer repository. :: Ongoing and Future Development Features that are in development for future releases include an auto-learning and graphically re-mappable JACK MIDI<->OSC gateway program tentatively named Non-OSC-MIDI-Mapper, which will simplify the connection of bidirectional control surfaces such as the BCF2000 to Non-Mixer. This program relies on Non's generic Control Signal layer on top of OSC. So it's not necessarily generally useful (although, in the future, it may be possible to use the `libmapper` library to provide the same functionality in a somewhat standard way). LV2 support is a frequently asked question. For various reasons, I currently have no plans to host LV2 plugins in Non-Mixer. But if anyone can come up with a compelling argument for LV2, or name one existing (libre) LV2-only plugin which couldn't be ported to LADSPA in a few hours that I couldn't live without having in Non-Mixer--I'd love to hear about it. I plan to re-factor Non-Sequencer to use the `nonlib` library common to Non-DAW and Non-Mixer. This will eliminate some duplicated code and allow for some of the user interface improvements seen in Non-DAW to be implemented for Non-Sequencer. It will also enable various forms of MIDI support in Non-DAW/Non-Mixer (it's not clear yet what forms this support might take.) Similarly, by using nonlib, OSC will be available in Non-Sequencer, probably taking the form of OSC control for pattern triggers and possibly pattern input. Also, with NSM's 'broadcast' capability, the holy grail of a shared tempomap is closer than ever. Another long-term goal for Non-Sequencer is to make the interface more compatible with touchscreen use, which I am better equipped to tackle now that I have a tablet like computer to play with. A near term goal for Non-Mixer is to add an option to that causes all mixer strips to run in a single JACK client. Conceptually, this is a horrible idea, but due to some practical performance limitations of JACK which affect users with hundreds of mixer strips, it may be a necessary evil. Leave it to JACK to design and advertise a feature (multiple clients per process) and then turn around and antagonize the people who actually use it. :: Project Notes Please keep in mind that the Non project is a one man show. I designed and implemented all of this stuff by my self, and at a considerable cost in time, sleep and energy. I make it available to you so that you can be free of the enormous burden of having to solve these complex problems yourself. I see chatter on various forums about forking the project, the project being dead, etc. Unlike some of the more heavyweight projects out there, Non has no corporate sponsor, and I have a complicated and turbulent existence which does not always allow me to devote my attention to purely intellectual pursuits. I welcome any and all contributions, whether they be in the form of code, documentation, testing, package maintenance, chocolate, roses, precious metals, priceless relics--whatever. If those who bring up the issue of forking really had the skill and energy required to do something better with Non-*, you'd think they'd at least try submitting a few patches to me first... I run Debian GNU/Linux and Non-* use a made-from-scratch custom build system which relies on accurate information from pkg-config. I cannot test on, or anticipate the quirks of, the hundreds of other Linux distributions out there. I have a policy of never committing code to the Non git repositories which does not build. Thus, if you are having a problem building Non on your system, chances are it's just because of some silly/simple quirk of the distribution you're using that could easily be fixed. However, I'm not going to scour the web looking for these reports. Unless you send a report to the appropriate Non-* mailing list, expect that your issue will never be resolved. As always, the best and fastest way to get anything fixed is to just fix it yourself and sent me the patch--preferably with a thorough explanation in the commit message of why it is needed and how it works, as the less time I have to spend reviewing a patch, the quicker it will be applied. And finally, a note to packagers: If you feel that there's something about Non's build system that you don't understand or feel like you have to hack around, please consider discussing it with me. I'm more than willing to make changes to the build system which make life easier for packagers and improve the quality of packages. Having flaky builds of Non-* in a distribution's packages isn't good for anybody. I've seen comments in distributions' packaging bugtrackers saying that Non is a dead project, that the "developers" (plural) are unresponsive etc. But I've never heard from these people. If they actually took the time to email me, they might have different opinions. :: Errata I do not recommend linking Non-DAW against FLTK 1.3.0. FLTK 1.3.0 introduced a number of bugs, one of which seriously impairs Non-DAW's graphics performance. Non-Sequencer and Non-Mixer do not use the features of FLTK that have become buggy, so if you only plan to use them 1.3.0 should be fine. 1.1.10, 1.1.9, and 1.1.7 work fine, however. In the future, I'll be maintaining a known-working version of FLTK along with the Non repository so that Non-* can be statically linked to the custom FLTK and avoid problems like this--and also allow many workarounds used by the Non-* programs to be removed in preference to fixing them at their source. If you decide to build FLTK yourself, don't forget to use the following configure options: --enable-threads --enable-shared --enable-xft --enable-xdbe ----- Non-DAW and Non-Mixer (and Non-Sequencer) can be acquired via git from the URLs listed on the Non website: http://non.tuxfamily.org ----- The shortlog from v1.0.0 to v1.1.0 follows: Jonathan Moore Liles (114): Mixer: Don't use Fl_Group::clip_children(), which was only made public in FLTK 1.1.10. Fix a 64-bit bug in LADSPAInfo. Fix another 64-bit bug in Module insertion. Fix a mismerge that caused meter indicators not to be updated. FL: Clip drawing of value of FL_Sometimes_Input when in non-input mode. Mixer: Set minimum size for main window. Mixer: Fix automatic row layout logic. Mixer: Don't die if user picks a submenu node in module context menu. Mixer: Destroy a module's parameter editor window when the module itself is destroyed. FL: Get rid of unnecessary call to clip_children(). Move non-daw scripts into timeline/ tree. Mixer: Save/load the control mode status of the gain controller as part of the mixer strip's state. Mixer: Improve spatializer appearance. Mixer: Report azimuth and elevation of panner points. Mixer/Module_Parameter_Editor: Automatically show panner control for module parameter pairs named Azimuth and Elevation. Mixer/Panner: Vary width of latitude lines. Module Parameter Editor: Don't use local allocation to store label. Mixer: Further improve the appearance of the Panner widget. Mixer: Fix azimuth/elevation reporting. Load current values in Module_Parameter_Editor. FL/Fl_Scalepack: Give scalepack the ability contain a resizable() child. Mixer/Mixer: Cleanup. Mixer: Auto-connect spatializer controls to spatialization plugins. Mixer: Cleanup. Mixer/Panner: Fix azimuth assignment. Make spatialization mode of controller_module more robust. Mixer/Module_Parameter_Editor: Don't point widow label at stack allocation. Mixer/Module_Parameter_Edtior: Silence compiler warnings. Mixer: Raise (arbitrary) maximum number of channels of JACK module from 6 to 16. Mixer: Fix callback delivery by Controller Module. Timeline: Fix 64-bit bug in interactive region trimming. Fix 64-bit bug in peakfile handling. Mixer: Explicitly link to libdl. Fix build being broken by some include defining a preprocessor macro for 'None' Mixer: Don't segfault when removing a module. Mixer: Don't segfault during teardown upon WM initiated exit. Mixer: Handle WM main window close event just like Quit menu comment (confirm save). Some distributions put --as-needed in pkg-config and fltk-config results. *See you in /dev/null* Some distributions put --as-needed in pkg-config and fltk-config results. *See you in /dev/null* Really. I do. Don't rely on 'Fl' symlink which only exists on Debian. Mixer: Add basic OSC support. Mixer: Add basic OSC control to Controller_Module. Mixer: Add commandline option for specifying the OSC port to use. Mixer: Allow clients to query for available OSC paths. Mixer: Ensure that JACK_Module passes chain_name_changed event to its Controllers. Mixer: OSC enhancements. Responsd to both exact (range limited) and Control Voltage (0.0-1.0 on */cv) input. Mixer: Make OSC ports a property of Module::Port, not Controller_Module. Therefore, all plugin parameters will be accessible via OSC. Mixer: Create unique OSC paths even when multiple instances of a module/plugin with the same name exist in a chain. OSC: Don't swallow up all parameterless messages. Mixer: Feedback control values to OSC senders. Mixer: Default OSC paths are CV. Use /unscaled for exact input. Mixer: Don't create/destroy OSC ports more often than necessary. Mixer: Update OSC paths upon chain/strip name change. Mixer: Add OSC section to documentation. Mixer: Display realtime parameter changes (initiated via automation or GUI) in Module_Parameter_Editor Mixer: Cleanup OSC value scaling/clamping behavior. Mixer: Fix behavior issues of Toggle controls. Mixer: Don't allow ',' in OSC paths. Mixer: Fix mirroring and OSC automation of Spatialization controls. Implement the Non-Session-Manager (NSM) Mixer: Fix GUI update on Controller_Modules being controlled via JACK CV. Mixer: Destroy instances of Controller_Module when the connected modules are removed. NSM: Process more than one message per wait cycle! NSM: Detect death of clients whose processes are not children of NSMD. NSM: Update documentation. NSM: Fix logic when waiting for clients to load. NSM: Support sessions spread across multiple servers. OSC: Process all available events in one wait cycle. Give Non-DAW the ability to detect Non-Mixer OSC servers via NSM broadcast handshake. OSC: Implement generic signal model with path auto discovery through NSM. NSM: Mutli-server fixes. Timeline: Don't die when not running under NSM. Mixer: Don't die when not running under NSM. FL: Fix an uninitialized value. Mixer: Fix an invalid read on strip destruction due to a missing lock. Don't poll NSM as frequently. NSM: Clients must use the same protocol (UDP,TCP) as NSM server. Timeline/Track: Avoid unnecessary drawing of occluded track box. Timeline: Add interpolation mode choice of Linear and None to Control Sequences. OSC: Save and restore OSC signal connections outgoing from Non-DAW. Timeline: Run OSC output in a dedicated thread. Timeline: Clock cleanup. OSC: Signal cleanups. OSC: Improvements to signal routing. Add libsigc++ as a dependency. Big OSC signal cleanups NSM: Add --detach option to nsmd. NSM: Add session locking to nsmd. NSM: Minor GUI enhancements. NSM: Don't forget to inform GUI of the removal of stopped clients when closing a session. OSC: Fix signal creation notification. Cleanup compiler warnings. NSM: Time client responses. Update documentation. Mixer: Document spatialization control for Ambisonics plugins. Mixer: Update documentation. scripts: Allow suggested packages. Everybody gets new icons! Also, .desktop files. Use getopt_long for processing command line arguments to Non-DAW and Non-Mixer. NSM: For lack of a better place to put it, add 'jackpatch' program to the repository. NSM: Minor cleanup. NSM: Update documentation. Add notes to packagers. Add 'gleam' inspired boxtypes to replace the ones in the gtk+ theme. Also, tweak crystal boxtypes. Mixer: Add new 'plastic' knob type. Make knob type to display configurable. GUI tweaks. Mixer: Try harder to avoid drawing meters more than necessary. Timeline: Work around bug in FLTK 1.3 when drawing a string containing only symbols. Mixer: Make slider types optional too. Timeline: Warn about buggy FLTK version. Mixer: Try to fix some weirdness with Controller Module knob display. Mixer: Implement mixer Strip import/export Update Non-DAW screenshot in documentation. Bump versions.

13 years, 8 months

Re: [LAD] audio on Raspberry PI

by Victor Lazzarini

Thanks, sounds good, I am thinking here: cheap synthesizer. Victor On 29 Feb 2012, at 10:40, James Harrison wrote: > Comes with a DAC, but no ADC as far as I can see. > > Cheers, > James Harrison > > > On 29/02/2012 10:30, Victor Lazzarini wrote: >> Does anyone know whether the Raspberry PI comes with a DAC/ADC? >> >> Dr Victor Lazzarini >> Senior Lecturer >> Dept. of Music >> NUI Maynooth Ireland >> tel.: +353 1 708 3545 >> Victor dot Lazzarini AT nuim dot ie >> >> >> >> _______________________________________________ >> Linux-audio-dev mailing list >> Linux-audio-dev(a)lists.linuxaudio.org >> http://lists.linuxaudio.org/listinfo/linux-audio-dev Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie

13 years, 8 months

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