Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

4 participants
7538 discussions

Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst

by Kjetil Svalastog Matheussen

Paul Davis: >>One thing that distinguishes dssi-vst from vstserver and jack-fst is >>that it manages threading in the Windows parts of the code using the >>Windows threads API rather than pthreads, which means it ought not to >>be sensitive to threading-related changes in Wine. Of course, that's >>only theory. > >the way wine now handles threading makes this point mostly moot. wine >completely overrides the pthread "vfunc" table for any NPTL system and >even (i think) newer linuxthreads ones. you may think your app calls >pthread code, but if its linked using winemaker, its not (at least, >not directly) :) and of course, the new version of fst will require >winemaker compilation as well. Yes, in theory, there should be no difference. But try to compile a shared library that links to libwine and use pthread functions, without linking with libpthread. This worked with wine 9.12.2003, but not anylonger. I had to use some crazy hacks on wine to make vstserver compile for about a year ago or something. And later it got worse (unable to compile). The way wine/winemaker constantly changes is so tiresome that I just don't want to touch it anymore. (Perhaps thing have got better now, though.) --

20 years, 10 months

[linux-audio-dev] LAC2005: Don't forget to floss^H^H^H^H^Hregister!

by Frank Neumann

Hi all, the 3rd International Linux Audio Conference(*) or "LAC2005" for short is nearing (21-24 April), and if you have not registered for it yet, now would be a good time to do so. It's free, we are not selling your email addresses (honestly!), and it gives you a real bonus: After a short negotiation with ZKM, we agreed that registered participants have free admission to the ZKM Media Museum and the currently running exhibition "Making Things Public". The Media Museum is quite interesting, especially since you can see a real computer monster in live and stunning action there: Recently, they have acquired a fully working Zuse Z22 from a local college. This lady is really worth being seen. Well, I digress. We hope to see many of you next week at the ZKM in Karlsruhe! The LAC2005 Organization Team: Götz Dipper (ZKM) Frank Neumann (*) http://lac.zkm.de

20 years, 10 months

[linux-audio-dev] Extreme (midi) omni-mode

by Jens M Andreasen

Hi! Say you had an external single channel midi module, and it wakes up in omni-mode (all channels are equal), you will ofcourse expect it to make a sound, no matter the settings on your sending keyboard. Now, suppose the module is multi-timbral? What is the expected result? 16 different sounds layered?. How? Why? Prior art? -- ( ) c[] // Jens M Andreasen

20 years, 10 months

[linux-audio-dev] Re: [linux-audio-user] Concerning libfst, vstserver, and dssi-vst

by Kjetil Svalastog Matheussen

Dave Phillips: > > Greetings: > > Users are constantly wrestling with issues surrounding the software > mentioned in the subject line, and I would like to find out what > directions are planned for those projects. Here's what I see now: > > 1. The vstserver project is functionally dead. It cannot work with > newer versions of WINE, and it appears that Kjetil does not plan to keep > it updated to accommodate the new versions. Alas, this also means that > his nice vsti, ladspavst, and k_vst~ projects are also unusable. :( > Vstserver does actually works very fine with newer versions of wine, at least the ones I have tried. But for compiling up vstserver, you need the 9.12.2003 version. And worse, the 9.12.2003 version doesn't work with newer versions of Linux, or something like that. (Ie. the workaround is that you first have to install wine 9.12.2003 to be able to compile vstserver, then install a newer versions of wine. The plugins will then use the newest version of wine). I think there exist a patch or something for the 9.12.2003 version of wine to make it compile with newer versions of linux (not sure which part). If anyone has such a patch, it would be nice if someone sent it to me. I'm still on Redhat 8 myself, so I don't know what the problem is exactly. > 3. The dssi-vst bridge is still unknown to me because of issues with > RH9, and I've not had time to test it on FC3. But is there any general > feeling that dssi-vst is a better route to take, at least for the normal > user ? Btw, I like the DSSI API, but it seems slow in catching on with > developers. Is that perception correct ? > I think dssi-vst looks very nice too (although I haven't tried it), and its very similar to the way vstserver works. It should not be much work to make vsti, ladspavst and k_vst~ work with dssi-vst instead of vstserver. But I don't have the time / other more interesting projects. > Please understand that I'm in no way criticising the work done on > these projects so far. In point of fact, I'm extremely happy they exist, > but I'm also in considerable doubt whether they can continue to be > useful without further maintenance. Users are writing to other users to > figure out how to fix small problems (usually with libfst), but these > repairs are not making their way back into the codebase, which seems > rather non-optimal to me. I'm also aware that the greater problems exist > because of WINE's inherent instability (WRT its development, not > necessarily its usability) and that Linux audio developers can't be > responsible for WINE fixes too. Perhaps more crosstalk between the WINE > developers and the LAD folk (similar to the recent discussion re: the > kernel list and LAD) would help smooth the way for a more consistent and > more manageable VST/VSTi bridge for Linux ? > > So, any comments or useful suggestions ? > There are two fundamental different ways to get vst plugins to work in linux with the help of wine. The fst-way and the vstserver/dssi-vst way. Both "ways" are needed. One of them is very fast, but hard to set up (fst). The other one is safer and slower, and a little bit less hard to set up. Problem is, that the releases most probably does now depend on a spesific version of wine, or will depend on a spesific version of wine in the future. It would be nice if the three projects (or at least fst and dssi-vst) was coordinated to use only _one_ version of wine, and that this version of wine is downloaded from one place, for example a sourceforge project place. But for this to happen, some person needs to step up, set up a sourceforge account, do some coding, coordinate the coders, release things, do some work. It might not seem like Thorben, Paul, Chris or myself is the right person right now. Perhaps there is some coder with some free time that wants to do this stuff? --

20 years, 10 months

[linux-audio-dev] qjackctl feature request

by Lee Revell

I've been testing jack.udp lately which involves running qjackctl on each machine over a remote X11 connection. However it's impossible to tell which qjackctl is running on which machine. I'd like to request that the hostname be added to the window title. Lee

20 years, 10 months

[linux-audio-dev] [ANN] jack-udpsync + second soundcard client

by torbenh＠gmx.de

hi... just some code i hacked the last 2 weekends. you know jack.udp ? this is jack.udp without wordclock reqirement. slaves one jackd to another. dig around in jack-dev list for more info. i am very interested in osx ports and PPC -> x86 tests. what is still missing is JackTransport propagation through the net. this is tested with -p 128 i dont know if MTU will get in your somewhen. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language

20 years, 10 months

[linux-audio-dev] compiling LADSPA for Mac OS X

by James McDermott

Hi all, has anyone compiled the LADSPA sdk for Mac OS X? I expect lots of people have, and that it's very easy..! In the src directory, I type make and get this: ld: unknown flag: -shared The targets in the makefile are: ../plugins/%.so: plugins/%.c ladspa.h $(CC) $(CFLAGS) -o plugins/$*.o -c plugins/$*.c $(LD) -o ../plugins/$*.so plugins/$*.o -shared ../plugins/%.so: plugins/%.cpp ladspa.h $(CPP) $(CXXFLAGS) -o plugins/$*.o -c plugins/$*.cpp $(CPP) -o ../plugins/$*.so plugins/$*.o -shared So I guess ld is different on OS X, and looking at the ld man page, I guess maybe I need -dylib instead: ../plugins/%.so: plugins/%.c ladspa.h $(CC) $(CFLAGS) -o plugins/$*.o -c plugins/$*.c $(LD) -o ../plugins/$*.so plugins/$*.o -dylib ../plugins/%.so: plugins/%.cpp ladspa.h $(CPP) $(CXXFLAGS) -o plugins/$*.o -c plugins/$*.cpp $(CPP) -o ../plugins/$*.so plugins/$*.o -dylib But now I get this error: ld: plugins/amp.o illegal undefined reference for multi module MH_DYLIB output file to symbol: dyld_stub_binding_helper from section (__DATA,__la_symbol_ptr) relocation entry: 0 and that's where I give up! But I guess there's a solution which is obvious to anyone who knows about dynamic libraries on a Mac?

20 years, 10 months

[linux-audio-dev] Creating the conditions for VST-like plugins on Linux.

by Juan Linietsky

Hi ! I'm writing this mail because at this point I'm seeing that the Linux Audio Development community is still going aimlessly on how to develop powerful audio applications. As we know, one of the key factors missing nowadays is audio plugins and synth plugins. Some audio plugin needs can be covered by LADSPA, but in other cases you need a lot more complex interfaces than just a few sliders.. (like is compressor with curves, graphical equalizers with band feedback, parametrics, multiband compressors, voice autotunning, surround spatial repositioning.. and everything available of course, that would become more intuitive and useful with more feedback) Also there is the need for instrument plugins, single or multi timbral (so you dont have to load all the instances at once). DSSI provides this (except the multitimbral) but you have to write the interface separated than the core, which not only is more difficult to program, but also very limiting because in many cases you cant show with much detail what is going inside the synth, like editing a sample, draw freeform envelopes, edit the oscilator generator, etc. And better not talk about effects, which need spectrums, vus, and other kind of complex feedback. So, I'm sure that many of you have asked yourselves, why cant we have a VST-like plugin architecture for Linux? The following are excuses: -Because we need core and interface separation, this way we warranty a clean design and network transparency -Because it would force both interface and core to be memory locked, as a result of being a jack clients, forcing more physical memory to be used -Because separating interface and core makes for a clear design. And I say, ALL THIS IS LIES. Every single of such reasons are of no concern to musicans. If I just want to make music, I would not care about any of such reasons. I'd just fire up an application and make music. All that seems to me more like academia-speech than real reasons. You can believe them or not, but it's PROVEN that none of these are needed to make music. However, there is a one and single reason of why we dont have VST-Like plugins in Linux: -It is impossible to make a plugin in a widget toolkit that will be hosted by another widget toolkit. (say, gtk on qt, or fltk on fox). Why is this? The answer is simple.. X11. An X client connects to the Xserver (via unix socket/tcp/wathever) then stays blocked in that connection until it receives events (keypress/mouse/etc), which are sent to the event loop. It is then the toolkit (gtk/qt/etc) the one responsible for handling the events. This way, even if you load many toolkits at the same time, and even each opens a connection... one of them has to stay blocked in the event loop. This is the REAL reason why we cant make a VST-Like plugin API in Linux, or EVEN port opensource VST plugins and use them here. Up to now, nobody has really bothered in solving this problem, instead most just attempt finding a workaround. So what I am proposing is to SOLVE this problem.. how? -Designing a library that will act as intermediate between the toolkits and the X Connection, handling the event loops for all of them, so they can run together. -Placing this library in freedesktop.org -Encouraging toolkit makers to support this library, and porting them to it As you see, this is not a simple task, and much less something I can do alone, so I will need help!! I am very sure that at some point we will get support from other groups which will also benefit from this. So before anything, I'd like to know who is interested in this, and who would like to help, offer experience, etc. Well, hope I get any feedback Cheers! Juan

20 years, 10 months

[linux-audio-dev] Chionic 1.0.0 Final (Sampler) Released!!

by Juan Linietsky

I have decided to put together a release and free Chionic to the world. Chionic is by far THE most advanced sampler that you can find for GNU/Linux, *BSD, Etc. It is not only extremely powerful, but t has everything configurable via UI. You can obtain the baby here: http://www.reduz.com.ar/chionic/ Lengthy, Lenghty, Insane List of features: 1.2.1 General * OSS and JACK Support (sorry, no time to make ALSA) * Integrated Virtual Keyboard for testing samples and patches (automatically detecting the mode in which you are). * Spectrum display for the output sound. * Voice Counter, so you can always see how many voices is Choinic processing. * Customizable Colors for some widgets. * Customizable keybindings for many widgets * Sliders all show the respective values, and offer small button so you can input a value by yourself, with the range and all presented. * Spinboxes go to top and bottom if you right click on the arrows. * Fully Functional ``Settings'' Menu.. no need to go like.. ``chionic -help'', tweak everything from the UI. 1.2.2 Samples * No, you dont control Samples directly, you have to make instruments. * Up to 1000 samples per bank * Loading of stereo/quadrophonic/whathever samples in as many slots as possible, or just merge into a monophonic sample, all upon import * Supports every single sample format thru libsndfile * Built in extremely complete sample editor with extensible plugins. This sample editor is meant for tweaking everything sample related: 1. Loop Begin/ Loop End. 2. Tuning, Autotuner. 3. Realtime centered zoom, from full view to individual samples using a slider. 4. Play Position Display! It displays the playback pointer INSIDE the sample, for every voice being played. * Sample Looping at any point, plus ping-pong (bidirectional) looping * Samples are stored in 16 bits normalized, then converted to 32bits floating point for mixing (not really any audible quality loss, since it's CD quality). * Samples are stored in a pool and become loaded on demand, when an instrument is using them or you are editing them. They are automatically freed when not using anymore. * If you permorm modifications to a sample in realtime, it will remain in memory until you save it, to avoid any kind of mistake. * Sample management is easy, with an interface full of indicators for the usage/refcount of every single sample. * Extremely fast resampler using selectable (cubic, linear, cosine or raw) interpolation method, which uses fixed point increment sections. You can have over 512 simultaneous voices with very little CPU usage. (yup!) on a 1Gz machine.. * The resampler also performs volume ramping and filtering, so the quality is perfect. * Integrated declicker, which will smooth out samples that dont start or end at DC. The result is a clean sound no matter if the samples have wrong DC. It also declicks samples that are being killed. * Experimental Sample mip-mapping feature.. in a way, it's the best upsampling interpolation you'd ever hear... in other way, it works like shit with looped samples.. as I need to refigure out how to make them.. so It's off by default. 1.2.3 Channels/Buffers/Buses/Sends/Inserts * Integrated Buffer Routing System, for assigning inserts and sends to your mix. * Integrated set of effects and presets for insert (Chorus, Reverb, Stereo FX, Stereo Echo, Band Limiter, 6,8,10,20,30 bands graphical EQs, OA-Pitch Shifter as internal plugins, plus LADSPA is supported too). * Sends can be assigned to midi controllers. * Very Smart algorithm for detecting inactivity of mixing channel buffers, so it can turn off inserts automatically when they are not used, for both internal and LADSPA inserts. * Buffer counter, so you can see how well the previous feature works :) * PANIC!!! button, to turn off all the voices. 1.2.4 Instruments * Unlimited Banks of 128 instruments for Patches * Patches are made by using samples from the pool * When a Patch is loaded, the samples are loaded too * Adjustable Velocity Sensitivity Curve * Pitch/Pan Scale and Center Separation, to be able to make piano-like instruments.. where the bass goes to the left, and treble to the right of the pan. * Inserts PER PATCH. Besides the other inserts, you can make an effect chain with the same internal and LADSPA effects that are bind to a Patch. Also, if you modify any parameter, it will be modified in realtime in all the channels where this Patch has been assigned too. * Up to 4 ``tones'' (sub voices) per Patch, each tone has: 1.2.5 Tones * Velocity Range (from which to which velocity does the tone accept notes) * Sensibility Curve Editing * Note Scaling, Coarse/Fine Tuning, Pan, Start Delay * Filters: Resonant LPF,HPF,BPF,BRF with Frequency Tracking for Cutoff, and Volume->Cutoff Sensibility in both ways. * Widget to edit the filter shape (cutoff/resonance) by just drawing on the Frequency Domain curve. * Randomness factor in all of the above parameters, for a more natural sound. * Freeform Envelopes (just draw a polygon) with Loop and Sustain Loops (which can take any 2 different points, so you can loop with any shape you want). The Display has Auto-Zooming and guides. Envelopes also display a one or more position guides which represent the place the envelopes are being played, in realtime! * LFOs (wich can be sync-ed or not) with sine, saw, square and noise waves, and editable Delay, Rate, Depth and Phase. * Envelopes and LFO for: Volume, Pan, Pitch, Cutoff and Resonance. Use all together if you want. * Sample/Note Table, to assign to EACH note, EACH different sample in the sample pool. * Of course, helper buttons for the above :) so it doesnt take a much time to do. 1.2.6 MIDI * ALSA_seq MIDI Input driver, can open up to FOUR ports, so you achieve 64 input channels. All channels are mapped into the buffers screen, and due to the optimized nature of Chionic, you can use all 64 of them without any slowdown. * Midi Jitter Correction. This means that you dont need to run JACK at low latency in order to avoid Jitter.. even at 16k buffer sizes, the midi sent to Chionic will sound fine, with no jitter. This was achieved using a very clever and complex hack, which shouldnt be there because JACK should support midi in the first place :) * Due to the wonderful nature of Linux, you have to make sure that nothing is stressing the /proc filesystem, or else the above feaure will not work correctly! Dont run any 'top' operations and BE CAREFUL with KSysguardd. Failure to comply with this will result in the midi sensing thread to improperly timestamp incoming events.. heck if I know why. * On the bright side, and if nothing of the sort is being done, you can run jack and chionic even as normal user and it's going to work fine. **************************** Sad News. I'm over with the development of chionic, on it's first release. I have to sadly accept that as much as it works the way I want, I cant communicate my sequencer to chionic in the way I need (because Jackd is too poor to do it the proper way). So in short, anyone who is interested in taking care of chionic for me and continuing development is MORE THAN WELCOME. I will gladly offer assistance on it's development. Also, choinic and it's Core/UI are separated at code level, so if you want to make a GTK app, or port it to Windows, it's not a hard task. Just let me know, so... CHIONIC IS DEAD UNTIL SOMEONE DECIDES TO PICK IT UP AND CONTINUE DEVELOPMENT (or until Jackd matures enough.. yeah right :)

20 years, 10 months

Re: [linux-audio-dev] Other real-time options

by Kjetil Svalastog Matheussen

Jean-Marc Valin: > Hi, > > I think a part of the conversation I had with Con Kolivas may be of > interest here: > > > <jmspeex> I still don't understand why this [unprivileged real-time] > hasn't gone in the kernel a long time ago. > <----> > <con> jmspeex since lkml is so hopeless as a forum for that sort of > thing, feel free to start an online petition to show how many people > there are. 1 of 2 things will happen - 1. you'll have thousands signing > up, or 2. there are less people doing it than you think This shouldn't be a problem. There are about 2300 subscribers to the linux-audio-user mailing-list: http://www.linuxdj.com/audio/lad/subscribe.php If someone sets up this forum, and more than twice of us sign up, that should show those arrogant lklm-people that there are really _a lot_ of us, and that we are strong, and very angry. Hah!

20 years, 10 months

Jump to page:

2026

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