Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

[linux-audio-dev] [ANN] Realtime Extension documentation for SND, and snd-ls V0.9.3.0

by Kjetil Svalastog Matheussen

The Realtime Extension for the sound editor SND consists of two parts: 1. The RT Engine - An engine for doing realtime signal processing. 2. The RT Compiler - A compiler for a scheme-like programming language to generate realtime-safe code understood by the RT Engine. Homepage: http://www.notam02.no/arkiv/doc/snd-rt/ Screenshot: http://www.notam02.no/arkiv/doc/snd-rt/screenshot.png ******************************************** Snd-ls v0.9.3.0 --------------- Released 19.5.2005 About ----- Snd-ls is a distribution of the sound editor Snd. Its target is people that don't know scheme very well, and don't want to spend too much time configuring Snd. It can also serve as a quick introduction to Snd and how it can be set up. Changes 0.9.2.0 -> 0.9.3.0 --------------------------- -Updated SND to v7.13 from 18.5.2005. Many important changes. -Fixed a small error in the installation script. http://www.notam02.no/arkiv/src/snd/

20 years, 5 months

Re: [linux-audio-dev] LADSPA Issues

by Mike Rawes

--- Dave Robillard <drobilla(a)connect.carleton.ca> wrote: > Hi all, > > A while ago I started a thread about the proper way to refer to LADSPA > plugins (in save files or whatever) and the consensus was library > filename + label. > > People have been having problems with library name - different packages > seem to make different names for the libraries (prefixing blop_, for > example) so it doesn't always work. Basically I think using shared > library file name is an awful way to reference plugins for numerous > reasons. As the guilty party (author of blop) I admit that when this option was added (--program-prefix for library files) it was done in blissful ignorance of the use of library basename as an identifier, as I had assumed that the Unique ID was as claimed in ladspa.h. The purpose was to avoid name clashes with generic names such as 'sawtooth' - I ended up copying swh, and append the UID (so it does have a use after all :) to the filenames. I'd meant to remove the --program-prefix option from configure, but forgot. > So why wasn't the unique ID the thing to use? There is a unique plugin > ID in LADSPA, if not for this then for what reason? Going by what is said on ladspa.org, I think that it was originally intended to be the way to refer to plugins, and changed as development progressed. IIRC, the UID is still required to lookup metadata with liblrdf, but this may have changed since I last looked. > In a similar vein, I really think the current system for LADSPA > distribution sucks - big tarballs from various devs containing heaps of > completely unrelated plugins. A centralized site where plugins can be > submitted on their own (or in related groups) would be a great thing, > IMO, and would make it easy to verify that unique IDs are in fact unique > to solve the above problem. I don't think you'll get very far arguing the case for UIDs - the arguments against were pretty clear in the previous discussion and summarised by Chris Cannam in his response. I think we're stuck with basename+label until a better scheme can be implemented, possibly for LADSPA 2. Regarding unrelated plugins in one library, I personally don't have a problem with this as liblrdf does a fine job of categorising plugins where it's really needed (in the host). > Right now if a developer wants to make just one random plugin, they > don't really have a sane way of getting it out there. I agree here. The best option short of creating a new library distribution is to get your plugin 'adopted' into an existing library. I'm certainly willing to merge any homeless plugins into blop. > I'm willing to full-time maintain the site, but I don't really have the > hosting/abilities to create it. What do the other plugin authors think > about this? I'm all for it. Maybe liase with Richard Furse to update the ladspa.org site itself? There's already a list of links there so all that is really needed is to add details for maintainers willing to adopt plugins, with appropriate provisions (kind of plugin, language, build system and so on)? - Mike ___________________________________________________________ Yahoo! Messenger - want a free and easy way to contact your friends online? http://uk.messenger.yahoo.com

20 years, 5 months

[linux-audio-dev] Re: Minimum reasonable latency

by Juhana Sadeharju

>From: Alfons Adriaensen <fons.adriaensen(a)alcatel.be> > >IFF JACK could be modified to allow this then probably you wouldn't >need M, its function would be taken care of by jackd. That was the idea. >The problem with such a scheme could be that the load is not spread >evenly, so it would be necessary to give those clients that use >longer buffers a lower priority. There may be other troule hidden >somewhere... Yes. The priority should depend on the buffer size. Longer buffers would run with non-soft-RT schdulers. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software

20 years, 5 months

[linux-audio-dev] Re: Minimum reasonable latency

by Juhana Sadeharju

>From: Benno Senoner <sbenno(a)gardena.net> > >Since we cannot increase the speed at which the sound travels and even >DACs add some latency (1msec or so) >I see any effort to reduce latency below 2-3msec quite useless. Lucasfilm's sound processor at 1983 had fixed 1.5 ms latency. But did they have as lousy DACs as we have today? Don't know. Did they mean the DSP effect processing latency only? Not sure. I dislike that the Jack buffersize must be turned up for all clients when one client does not perform well. It well could be that I would like to use the buffersize 32 for A/D --> EQ --> M --> D/A and the buffersize 256 for Zyn --> M --> D/A (the part M --> D/A is the same as above) where M is a magic processing node which mixes the audios having different buffersizes. M would be quite simple, actually. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software

20 years, 5 months

[linux-audio-dev] Guidelines for developing a music editor

by Toby

Hi LADs As you might remember from my recent questions about MIDI tuning and microtonality, I'm currently designing a music editor unlike any other (that I've seen.) It will be a graphical music editor, similar to existing "piano roll" editors on the surface, but with several important differences. It will be a tool for composing music in Just Intonation. It will also be free software (that goes without saying :-) Anyway, I need to make a few key decisions about it and I'd like to have some feedback and advice from you experienced people! The most important issue is how to integrate my editor with the greatest possible number of synths and other existing music sofware/hardware. Unfortunately my software will need to set the pitch of every single note independently of the others, so "common" MIDI will not suffice. Pitch bend will not work either, or rather it will limit the output to one note per MIDI channel. Not adequate at all for most uses. In the other thread you kindly provided me with some advice and links, including mentioning the MIDI Tuning Standard and OSC. I'm designing my software with extensibility in mind, so adding new protocols will not be a problem. Nonetheless, the more protocols and APIs I know of in advance, the more extensible I can make it! I have heard of several standards in the Linux audio world, thinks like Jack and ALSA. But I'm quite new to all this, so I don't have a good idea of what standards is a modern music editor supposed to support. Could you please mention them to me? I will gladly study the APIs on my own, but I don't want to waste time studying stuff that has no practical value for building a graphical music editor. Also, please keep in mind my special needs about note tuning/microtonality. I hope this is not considered a repeat of my previous email... I've read quite a bit of docs in the meantime, but I'm still confused. Is an editor supposed to do something with Jack? I'm handling the "editing" part on my own, but how should I embed playback/recording functionality into my editor? Is there a way to interface it with VST plugins (where binary compatible) and/or any free alternatives? Should I do all this on my own, or are there any architectures that I could simply plug into? Regards, Toby

20 years, 5 months

[linux-audio-dev] re: Does anyone have a working example of Supercollider and SCUM GUI where slider or a button does real-time update on the synth

by Ivica Bukvic

Hi all, I just realized why my example code "didn't work." It was a simple stupid human error (surprise, surprise), the change did occur, it was just that the sinetone was 400Hz and I was altering it by 0-1 Hz with slider output which on my lousy laptop speakers in a noisy room seemingly did not make a bit of difference (at least not to my ears :-). Anyhow, thank you very much all for your help in this matter! Btw, Stefan, you mentioned that there were some updates to SCUM. Are these included in the latest 0.0.2a version? Also is this the same version like the one presented at LAC last year? Many thanks! Best wishes, Ico

20 years, 5 months

[linux-audio-dev] Does anyone have a working example of Supercollider and SCUM GUI where slider or a button does real-time update on the synth

by Ivica Bukvic

Greetings all, I guess title says it all. I do have working examples (i.e. the sequencer example from the LAD 2004) that make new instances of synths but none of them actually do real-time updates to existing instances. At any rate I would greatly appreciate your help in this matter. This is as far as I got and cannot figure it out beyond this point (my brain is pretty darn fried :-): s = Server.local.boot; SynthDef("onetwoonetwo",{ arg out=0, freq; w = SCUMWindow.new; w.title = "Slider example"; w.initialSize = Size(20, 300); c = SCUMVBox( w ); v = SCUMSlider(c, { |v| v.expand = 1; v.fill = 1; v.bgColor = Color.white; v.fgColor = Color.black; v.action = { freq = v.value * 100; }; v.doAction; }); w.show; Out.ar(out, SinOsc.ar(freq + 400, 0, 0.5) ) }).play; What I am simply trying to do is to affect the frequency of the sinetone by moving the slider, yet nothing changes when I move the slider. Any help would be greatly appreciated! Best wishes, Ico

20 years, 5 months

[linux-audio-dev] Bug in RT Pre-empt Kernel Patch?

by Shayne O'Connor

i've just compiled a 2.6.12.RC4 kernel with the rt-preempt patch (configured with PREEMPT_RT) and it all went ok, but after installing the binary Nvidia drivers, i get this bug message: BUG: modprobe/2085, lock held at task exit time! [de2887e4] {(struct semaphore *)(&os_sema->wait)} .. held by: modprobe: 2085 [dfceec30, 118] ... acquired at: os_alloc_sema+0x40/0x76 [nvidia] should i send this to the kernel list? will this cause problems on my system? shayne

20 years, 5 months

[linux-audio-dev] Aeolus and OSC - comments requested

by Alfons Adriaensen

Hello all, I'm planning the OSC-fication of Aeolus, and would like to have some comments / feedback on the current ideas (they could well be braindead, in which case you are kindly requested to say so). The setup I have in mind is as follows: - There will be one UDP server socket. This socket is left unconnected, and will receive OSC commands from any source. These commands give you complete control over most aspects of Aeolus (excluding the stop definition editor which will remain in the local GUI only). They will also include note on/off comnmands, and that leads to my first question: is there any "standard" OSC format for these ? - This interface will provide everything required by sequencers etc. that want to 'play' Aeolus. Clients that want to implement their own user interface will need more: they also require feed- back on the current state (e.g. if a midi messages recalls a program, this should be reflected in the user interface). The way I currently foresee providing for these is to add the commands: /addclient ,s host:port and /remclient ,s host:port Registered clients can request information (e.g. a list of all available stops), and will receive notification of everything that may affect a user interface, again by UDP messages to their port of choice. They will still send all their commands to the unique server port above. Second question: is this a good idea, or would it be better to create a TCP connection for this type of client ? Comments invited !! -- FA

20 years, 5 months

[linux-audio-dev] new seq24 article on-line

by Dave Phillips

Greetings: Linux Journal has published my little article about seq24 : http://www.linuxjournal.com/article/8304 In case anyone's interested... Best, dp

20 years, 5 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