Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

by Louigi Verona

Hello fellas! You probably bumped into one or two videos of AudioGL, a sort of modular DAW (http://youtu.be/bCC9uHHAEuA). Of course, none of us knows whether the video is actually true, whether it is as as smooth as it appears to be, whether it really does work that well as seen in the demo. However, assuming that it is, it does display a rather robust music production environment. I have two questions. 1. How is it possible that such complex functionality seems to run that smoothly? Or does it look more complex than it really is? The GUI seems very responsive and animated. 2. The project seems to be developed just by one person, yet it looks like a very functional music sequencer. Am I missing something here or is it a matter of personal talent and commitment? Cheers! -- Louigi Verona http://www.louigiverona.ru/

13 years, 3 months

Floating point Denormals: C++ and Waf

by Harry van Haaren

Hi all, I've working on a LV2 instrument plugin, and it consumes about 1-2% CPU on idle. When I leave it for about 20 seconds, the CPU usage jumps to 38 / 40 % of a core, and JACK xruns. The code contains IIR's for a reverb effect, so I'm going to blame this CPU burning on denormal values. I'm using waf as the build system, and appending "-O3" and "-ffast-math" to the CFLAGS and CXXFLAGS. Building with ./waf -v shows the runner thread to have the "-O3" and "-ffast-math" in the command. Yet when I run it it still hogs CPU after about 10-20 seconds. Reading on gcc's pages (http://www.acsu.buffalo.edu/~charngda/cc.html) tells me that if DenomalsAreZero and FlushToZero are set, it should be linked with crtfastmath.o. I don't know how to check if this is happening? I'm not sure where to look next to fix the problem. Help appreciated! -Harry

13 years, 3 months

LV2 Achievement of GMPI Requirements

by David Robillard

I have adapted the GMPI requirements final draft document to a comparison with the current state of LV2: http://lv2plug.in/gmpi.html A couple of nonsense baroque ideas aside, most of the requirements are met, though there are still important gaps. I mention it here in case anyone has an interest, please feel free to address any of the points made in this document. It may also be useful to augment this document with additional requirements, particularly since there's several knowledgeable folks who may not grok the *how* of LV2 but know *what* they need in terms of general requirements. I will add a section for this if anybody has any input. Perhaps this will serve as a good road map that is not too bogged down with details. Cheers, -dr

13 years, 3 months

The Influence of the Actor Model (Praxis architecture 101)

by Neil C Smith

Hi All, I know I've posted an announcement about Praxis / Praxis LIVE here before. Thought a few people might be interested in this blog entry about Praxis' underlying architecture and the influence of the Actor Model. Be really interested in any comments with thoughts, insights, corrections, stupid mistakes, similar models in use elsewhere, etc., etc. http://praxisintermedia.wordpress.com/2012/07/26/the-influence-of-the-actor… Thanks in advance. Best wishes, Neil -- Neil C Smith Artist : Technologist : Adviser http://neilcsmith.net Praxis - open-source intermedia system for live creative play - http://code.google.com/p/praxis OpenEye - specialist web solutions for the cultural, education, charitable and local government sectors - http://openeye.info

13 years, 3 months

Re: [LAD] LV2 Achievement of GMPI Requirements

by Jeff McClintock

> > For historical interest. I did complete the GMPI prototype. > I don't suppose the code for those modular synthesis plugins is > available? :) I release as many as possible open source. Unfortunately before I used plugins I coded everything as part of my application, so a most of the good filters, Oscillators etc are not available as plugins, when I have time I'll do more. The stuff I have released is included with the SDK... http://www.synthedit.com/software-development-kit/ It's pretty specific to SynthEdit and the SEM SDK though so might not be much help to anyone. > > The SEM DSP Plugin API has a total of four functions { open(), setBuffer(), process(), receiveMessageFromGui() }, > > the remainder of the spec is covered by metadata. > Did you consciously decide to use a setBuffer method for some reason? > I consider that (connect_port in LADSPA/LV2) a mistake and efficiency > problem. Passing an array to process is better. [Plugin]--buffer-->[plugin] I use the same buffers over and over, so I inform the plugin once of the buffer addresses, then I need not do so again. Not passing an array to process() is less overhead on the function call... But I think any efficiency gain would be minimal either way, passing an array to process is probably just as good. > A requirement specifically about a strong and sensible plugin/UI > separation would have been a good one. By far the worst thing about > porting VSTs with GUIs. A free for all for UIs to screw with DSP code > is insane. Absolutely. The GMPI model is complete separation of GUI/DSP. The GUI has no direct access to the DSP. When the GUI tweaks a parameter it does so only via the Host. The GUI can run on you iPad, the DSP on you Linux box. No special plugin code for that scenario, it's transparent. Very clean. > > This point is simply that you > > should not actively *disallow* copy protection, and that you can check for > > example that the plugin is GPL *without* instantiating it, (because a host > > might want to check the license before unintentionally breaking that > > license by linking to the plugin). > > Fair enough, I guess I will just list this as met. I felt compelled to > at least hint that LV2 is not the sort of project that would ever > consider including evil software crippling garbage as a requirement ;) Understood. GMPI was for both commercial and free software. > "Including" MIDI is not a burden, it is a trivial consequence of having > a sane event mechanism....Not allowing for MIDI is completely unrealistic, > and would mean plugins can't work with by far the most common format of > musical control data, and porting existing code to work as a plugin > become dramatically more difficult. Clearly a loss. All you get > trying > to do things that way is endless mailing list fights about whether to > mandate MIDI, or OSC, or the new Ultimate Control Structure, or > whatever > - a waste of everyone's time. Yeah, I do support MIDI via 'events', MIDI was trivial....but..... My concept with GMPI (not everyone agreed) was that MIDI was not required *in* the plugin. For example take your MIDI keyboard's "Modulation Wheel". Imagine the function that parses the MIDI bytes, decides what type of MIDI message it is and typically converts that 7-bit controller to a nice 'float' scaled between -1.0 -> +1.0. Typically every single VST synth plugin has that code. The inefficiency is that 1000 Plugin developers had to create and debug equivalent code. I decided the *host* should provide that routine. Written once, available to every plugin developer. The plugin simply exposes a port, and the metadata says "map this port to MIDI modulation-wheel". The advantage is - very rich MIDI support is available to ALL plugins. Not just the standard 7-bit controllers, I support CC, RPN, NRPN, SYSEX, Notes, Aftertouch, Tempo, almost everything. The MIDI parsing code exists only in one place so it's robust, and it saves plugin developers a lot of wasted time duplicating existing code. Plugins are small and lightweight, but MORE functional than the average VST plugin. With VST it's a mess. Developers MIDI support is highly variable, almost none support SYSEX for example. Half of them can't handle NRPN properly if at all. The other advantage is that with MIDI abstracted and presented as normalized 'float' values, the host can substitute OSC or HD-MIDI control without changing the API. Your existing plugins become 'hi-definition' and 'OSC capable' without any effort. You don't have to argue "MIDI vs OSC" because both are possible. Back then I said 'no MIDI in GMPI' - it was interpreted as highly radical and everyone hated the idea. I should have said 'MIDI parsing provided as a service to the plugin'. You have to write the MIDI parsing anyhow, why not make it available for everyone? > That said, sure, MIDI sucks. Something better is needed, but certainly > not some One Ultimate Control Structure to the exclusion of everything > else. All I've done with GMPI is recognise that MIDI controllers can be 'normalised' and presented to the plugin as nice hi-definition floats using the event system (atoms?). The plugin 'has no MIDI', no crufty 7-bit crap, yet is fully compatible with MIDI. That's my rant over ;) Best Regards, Jeff

13 years, 3 months

Re: [LAD] LV2 Achievement of GMPI Requirements

by Jeff McClintock

> I have adapted the GMPI requirements final draft document to a > comparison with the current state of LV2: http://lv2plug.in/gmpi.html For historical interest. I did complete the GMPI prototype. Now running on Windows (GUI + DSP support) and Mac/Linux (DSP support). We have over 1000 plugins available on Windows, mostly related to modular synthesis (because that's my interest). This year I ported the SDK and several plugins to Mac, and will also be ensuring they run on Linux (Waves Plugins Ltd have a high-end Linux-powered mixing desk that runs plugins. It handles mixing and effects for large consoles and runs at a rock-solid 1 ms latency). .SEM Comparison with GMPI... http://www.synthedit.com/software-development-kit/sdk-version-3-documentatio n/specifications/ SEMs main differences with LV2: * Sample-accurate parameter updates via time-stamped events. * Provides a performance optimization mechanism for handling silent audio streams. * Supports fractional pitch numbers. * Provides the ability for an instrument to define an arbitrary set of parameters that applies to each voice Comments on LV2..... >53 Disagree - Achievable entirely with metadata. If a feature is achievable with metadata, then you DID MEET that requirement (in a cool manner). The spec doesn't say HOW to meet the requirement. Update your table to say 'Met' on these requirements. The SEM DSP Plugin API has a total of four functions { open(), setBuffer(), process(), receiveMessageFromGui() }, the remainder of the spec is covered by metadata. >61 ...It is unclear what "patches" means here. It means presets. Or more generally save/restore the plugin's state. It doesn't mean the plugin *cares* about presets (like VST2), presets can be concept the host entirely takes care of. >73 "GMPI must define a simple in-process custom UI mechanism. " Disagree - It is unclear what this requirement means. It means the SDK should support GUIs, for example VST provides for opening a OS 'Window', what and how you draw inside that window is not specified. More importantly the API has a mechanism for tweaking the plugins parameters from the GUI. The crux is not that the API supports graphics or drawing, but that it supports communicating with the plugin from an abstact 'control surface' potentially running in a separate thread or even a separate process space. i.e in SEM the API supports a 'GUI' class getting/setting any of the plugin's parameters in a thread-safe manner. >101 "GMPI should allow for copy-protected plugins" Disagree - LV2 is not and should not be encumbered with specific "copy protection" mechanisms. I would say LV2 MEETS that requirement. This point is simply that you should not actively *disallow* copy protection, and that you can check for example that the plugin is GPL *without* instantiating it, (because a host might want to check the license before unintentionally breaking that license by linking to the plugin). All in all very good to see GMPI requirements used as a benchmark. A lot of smart people put many months into GMPI. I think it was considered 'too radical' at the time (the utter crap VST2 was considered ideal by many, and still is). My suggestion that it didn't need MIDI at all (MIDI being too limited and crufty) resurfaced in VST3 Note-expression. What we see now with LV2, SEM and VST3 is a vindication of GMPI actually being ahead of its time. Jeff McClintock www.synthedit.com Best Regards, Jeff

13 years, 3 months

Re: [LAD] [LAU] [ann] out now petri-foo 0.1.85

by rosea.grammostola

On 07/30/2012 03:12 AM, James Morris wrote: > (1.0) Non Session Management support Nice to see a dev who's taking this up. Session management a 'must have' for jack standalone applications and imho NSM is the best option for this. Best regards, \r

13 years, 3 months

[ann] out now petri-foo 0.1.85

by James Morris

Petri-Foo, the fork of the soft-sampler known as Specimen, has a new release, 0.1.85, available: http://sourceforge.net/projects/petri-foo/files/Source/petri-foo-0.1.85.tar… This new release brings two and a half new features with it: (1.0) Non Session Management support (2.0) 'Full Save' functionality (2.5) Import (1.0) NSM support can only be built if the system has liblo installed. If liblo (the lightweight OSC implementation) is _not_ installed petri-foo will be built _without_ NSM support. (2.0) "Full Save" functionality increases the portability of Petri-Foo's 'dish files'. A dir is created (the bank dir) containing the dish file along with symlinks to external samples used. the bank dir can then be archived using `tar -h`. To use full save, just select 'full save as' instead of 'save as' from the file menu. Selecting 'save' will do the right thing after doing so. (2.5) The import function is very self explanatory: it loads a dish file without deleting the existing patches. http://sourceforge.net/projects/petri-foo/files/Source/petri-foo-0.1.85.tar… Further resources: http://petri-foo.sourceforge.net https://sourceforge.net/tracker/?group_id=404816 http://lists.sourceforge.net/lists/listinfo/petri-foo-devel http://github.com/jwm-art-net/Petri-Foo Cheers, James.

13 years, 3 months

Lisalo 1.4 Release

by Nils

Lisalo - Linux Sampler Loader - is a command line program that loads entire directories of sample files, a single .sfz file or takes instructions from a meta .lsl file with relative paths to samples. Now you can quickly and easily load sampled instruments without even starting a GUI. This is release 1.4, grab it here, no installation required git clone git://github.com/nilsgey/Lisalo.git [New Features] -Jack Autoconnect-Port for the stereo sum/mix channels can be given from the command line -Can start Linuxsampler with a given server-address and port, which makes multiple instances possible -Jack Midi In for autoconnection is a commandline parameter. There is only so much you can implement into a tool that aims to be small by design. This marks my "feature complete" milestone. Future releases will be bugfixes. One example what you can do now: I use it to load the Salamander Piano shortly after boot and connect it to my ALSA midi port (which is always on, no matter if the keyboard itself is switched on or not). I now have instant piano sound whenever I switch my keyboard on. It does not conflict with other lisalo or Linuxsampler sessions. With this lovely one liner: /usr/bin/lisalo /home/nils/samples/sfz/SalamanderGrandPianoV2_48khz24bit/SalamanderGrandPianoV2.sfz -m alsa_pcm:Hammerfall-DSP/midi_capture_1 -p 7777 -m Salamander > /dev/null [Contact] https://github.com/nilsgey/Lisalo info@... irc.freenode.org #laborejo Feedback and chatting are welcome! Nils

13 years, 3 months

Praxis LIVE screencasts / good screencast software for audio?

by Neil C Smith

Hi All, Firstly, finally got around to some screencasts of Praxis LIVE in action - http://praxisintermedia.wordpress.com/2012/07/30/video-rough-cuts-1/ These are just 'rough cuts', unedited except titles and no voiceover. Only first 2 have audio, and the audio on the second is a little off in places (see below!) Secondly, anyone got a suggestion for screencast software that's good at glitch free audio? These are done with Kazam. First is mostly OK, but the second is a little glitchy. Finding only about 1 in 4 captures is any good - all sorts of weird glitches and sometimes speed issues, though the audio playback while recording is fine. Thanks and best wishes, Neil -- Neil C Smith Artist : Technologist : Adviser http://neilcsmith.net Praxis - open-source intermedia system for live creative play - http://code.google.com/p/praxis OpenEye - specialist web solutions for the cultural, education, charitable and local government sectors - http://openeye.info

13 years, 3 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