Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

by Ross Clement

Hi. Thanks of the responses (I only just got the linux-audio-dev digest). As some people have noticed, my queries are at an early stage. No, I don't yet know too much about the way that the SC code works. (i) Yes, the gui is going to be the major problem. However, while I have only used the demo version, and not the latest version, I don't remember *that* much complexity in the gui. The graphic version may be more tricky. (ii) What I meant by a source code to source code cross-compiler is this: I don't want to be in the situation where I port one version of SC (providing that this ever happens, I'm still asking questions on the SC-dev list to find out the status of any linux port), and then have to do the same work for a later port. What I wanted to do is the following: Find the Mac-specific OS calls in the SC code, and understand what they do (sound, gui, and other). Then, write an extra module of code declaring the same functions, with linux specific code to achieve the same effect. Yes, I know this is likely to be complex, and may require the creation of a fairly large number of objects. Then, for things that cannot be so easily fixed, like OS and/or gui toolkit #includes, write a program that will modify the source code into a form so that any more missing bits can be fixed. If I can do this, then hopefully the effort in porting future mac OS releases would be much easier. I.e. unlike a traditional source code to source code cross-compiler that would compile (e.g.) fortran to C, I'll be compiling max-os specific c/c++ into linux c/c++, hopefully eased by the creation of a set of libraries of 'faked' mac os x calls. (iii) Basic linux audio code samples will be of use, as I need to understand both systems to do the patching described in (ii). So, I'll look some up. And, (iv), though I should have mentioned this more explicitly in my first email, I'm also interested to know if someone's doing this already. Cheers, Ross-c

22 years, 12 months

Re: [linux-audio-dev] Re: SysEx interface for softsynths [was Re: [linux-audio-dev] LADSPA and TiMidity++]

by John Lazzaro

> I didn't see a way to contact them via email, otherwise I would inquire > as to how to proceed in getting an ID. http://www.midi.org/about-mma/mfr_id_app.pdf ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------

22 years, 12 months

[linux-audio-dev] [ANN]: New version of RTMix 0.48 now available for download

by ico＠fuse.net

Apologies if this is not going onto the right mailing list. I am mailing this from the ICMC2002 conference in Europe and am unable to have long-term access to the Internet, so I apologize if this has been posted in the wrong place. Anyhow, I would like to announce immediate availability of RTMix v.0.48 with binary, source code, and currently limited number of tutorials and docs, downloadable from: http://meowing.ccm.uc.edu/~ico/ (there is a non-flash version of the site for low-bandwidth users) New features and improvements since the version 0.16 are too numerous to state, so if you are interested in finding out more, please visit the website for more info. Hope everyone's summer was as eventful as mine :-) (I became a father of a beautiful son Sebastian and got an opportunity to present RTMix on one of the most prestigious international conferences associated with computer music :-) Greetings all! Sincerely, Ivica Ico Bukvic

22 years, 12 months

[linux-audio-dev] HDSP + cardbus

by D R Holsbeck

Ok so I got everything into a nice new rack, and quadruple checked my setup, and I still get a vocoder effect when trying ty play snything through my Digiface/cardbus interface. The Digiface works fine when connected to the pci interface, but not the cardbus interface. The modules, need the load/reload trick, to get jack to work with the pci or cardbus interfaces. So that seems nomal. I do get sound out when connected to the cardbus interface, but it sounds like it is being run through a very bad vocoder. I think somebody else has the same setup. H-DSP + cardbus, running. So Im pretty sure this should work. So if anybody has the magic incantations to make this work, I would be very appreciative of any words of wisdom they care to share ;-) System info Thinkpad A31 (P4 1.7g 256m ram) Alsa from cvs as of a month ago Debian 3.0 distro -- drh(a)niptron.com Great spirits have always encountered violent opposition from mediocre minds. -- Albert Einstein They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- Carl Sagan

22 years, 12 months

[linux-audio-dev] Basic information

by Ross Clement

Hi. Could anyone point me to some very basic information to give me some idea of programming for sound in linux. I have previously programmed sound on Silicon Graphics machines and Sun machines. I'm thinking about linux in the context of *possibly* building a cross- compiler (source code to source code), or similar, for porting the Mac OS X version of SuperCollider to linux, depending on various things (I have just sent an email to the supercollider development list). Supercollider is at: http://www.audiosynth.com It is an amazing piece of software, truly amazing. Thanks in anticipation, Ross Clement.

22 years, 12 months

Re: SysEx interface for softsynths [was Re: [linux-audio-dev] LADSPA and TiMidity++]

by John Lazzaro

> Richard Bown <bownie(a)bownie.com> > > Perhaps we could either approach a small company that has an ID already or > reuse one that's pretty old and likely close to defunct (again with the > owner's consent). I wonder who controls their use or if it's a case of > suck-it-and-see? http://www.midi.org/about-mma/mfr_id_app.pdf Don't even need to join the MMA, just send in your yearly check for $200 and the ID is yours. There is another route, though -- if: http://www.borg.com/~jglatt/tech/midispec/id.htm Is to be believed, its consider OK for one manufacturer to clone the SysEx commands of another -- as long as the cloners don't extend the space in any way. So, if there's an existing MIDI device out there that has an acceptable SysEx command space for your project, you're free to clone it. Actually, I have a hard time believing that is true in this age of intellectual-property restrictions, but MIDI does predate that era by 20 years or so, so maybe its just a part of the culture ... I do know all sorts of devices advertise "JL Cooper compatibility", but I don't know if this means that they really return the JL Cooper SysEx bytes when you do an identity request ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------

23 years

Re: [linux-audio-dev] LADSPA and TiMidity++

by John Lazzaro

> david(a)gardena.net writes: > I was thinking about CCs, Program Change and stuff. Is there a > standard way of asking a synth for the names of it's patches, or > which CCs are assigned to what, for example? This does seem like the sort of device-independent info that could be a part of the General Information Univeral ID (0x06 Sub-ID), but I've never seen it -- maybe someone with the MMA document handy could check for sure. This sort of "request-reply" transaction is the sort of thing the GI UIDs do, such as the Identity Request/Identity Reply: http://www.borg.com/~jglatt/tech/midispec/identity.htm Identity Request/Identity Reply returns enough information for a patch editor to know what Manufacturer SysEx commands the device understands. Although a major undertaking, it is probably is in the realm of the doable to: -- Look at a bunch of synth manuals, and see the general device-dependent commands it uses to send back items like the name of the patch. -- Make a small "seed" database of SysEx commands for a few types, and write code that reads the database format. -- Make a networked system for motivated users to send you back updates for the database with their own synth. In other words, distribute the legwork of finding out all SysEx command variants for every type of synth, to the vast userbase :-). Sort of like CDDB, but on a smaller scale ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------

23 years

[linux-audio-dev] ADM: problem solved (was: Re: adm: problems with mailing list web archive)

by Kai Vehmanen

Hi, searching the laa/lad/lau web archives is back online! Let me know if you notice any problems. links: http://www.eca.cx/laa http://www.eca.cx/lad http://www.eca.cx/lau On Sat, 24 Aug 2002, Kai Vehmanen wrote: > The htdig-installation that is responsible for the search > functionality of LAD/LAU/LAA web archive, is temporarily disabled. -- http://www.eca.cx Audio software for Linux!

23 years

[linux-audio-dev] interesting post from vst-plugins on float/int

by Paul Davis

i thought this was pretty insightful. vst-plugins has had a little debate over whether or not VST should provide an integer sample format. actually, not much of a debate. one person suggested it, everybody else jumped on him. this post, however, is the most detailed on why you should forget about thinking of float arithmetic as slower than integer ... --;p ------- Forwarded Message Date: Sun, 15 Sep 2002 14:21:52 -0700 From: Vesa Norilo <vnorilo(a)siba.fi> To: <vst-plugins(a)lists.steinberg.net> (VST PlugIns) Subject: [vst-plugins] Re: SDK buffers from host Ah, good ol' Mike Abrash. But do yourself a favour and update your knowledge: I'm pretty sure Mike has also done just that. BTW, I did learn a huge amount from his Zen of Code Optimization, but almost everything in it has become irrelevant by superscalar processing and vector engines. > > i think you are seriously and dramatically underestimating the > > incredible benefits provided by a standardized > I haven't count cpu instruction cycles recently. But last time > I did, the difference between floating point operations and > integer operation was from 15x to 100x speed difference. I > think though with the last few generation of cpu's they have > significantly narrowed the gap. On AMD 3DNow, all floating point instructions take 2 cycles, and two of them can be run in parallel, meaning that a total of 4 floating point additions or multiplies can be executed in 2 clock cycles. These also include sine, cosine, reciprocal and square approximations. Can you beat that with integer asm? > Again in my very limited audio processing experience so far > I'm finding that I can apply many of the same asm techniques. > And I know things are changing with new hardware I guess it's > possible in the future that floating with equal or, I don't know how, > but I suppose could even exceed int speeds. Since I have AMD, I'm fluent with 3DNow and not SSE. But from what I know, SSE is very similiar in functionality and power to 3DNow, and SSE2 offers even more capabilities. To beat the vector engines, you would have to go MMX. This is for two reasons: the saturating adds would eliminate the need of overflow checking, and due to its SIMD nature it can match or outdo 3DNow/SSE. Unless you are willing to drop to 16 bits (so that MMX can do 4 operations per instruction) it will not. > But when you get right down the heart of the matter, the > computer really is only doing bit manipulations anyway - > floating point or int. The difference with IEEE floating is the fact Which is why integer bit mask operations are still usable with floats, making many neat tricks possible. Such as really fast logarithms, which is again impossible with ints unless you use lookup tables (which you don't want to do for 32 bit resolution) > that the cpu has to decode the register to get at the exponent. > And that is going to add extra clock cycles. 2 sign bits have So, if an instruction that performs two floating point multiplies costs 2 cycles (and can run parallel with another such), each floating point multiply will consume 0.5 cycles. I don't really see any "extra cycles" here. Do you? > Still the ideal speed approach is a flat bit array with no decoding > and a big register, big enough to handle that largest number > you will ever have to deal with. That's very untrue. Consider how much memory speeds are limiting processing speed. Processing 32 bit floats is faster than 64 bit ints largely for that reason. The optimal speed approach is not simple. It has to do with optimizing memory for cost/benefit, optimizing cache and processor for speed, and trying to strike a balance. Consider floats as a hardware accelerated compression method that saves memory bandwidth. > What's wide enough for audio processing (64 bit???, 128 bit???). > At some point need for an exponent simply disappears. And the need for a 4GHz bus appears. > But you all are right. In reality it seems my lack of experience > has jump up and bit me in the ass. And I was only looking at > things from my self-absorbed world of the plug-in I'm trying > to build to do some specific things I personally would like to > accomplish. That's nice, but to recapitulate, don't really talk about optimization before you know several SIMD sets by heart. Nowadays, that's mandatory. > For the above reasons under optimized assembly language > conditions, I just don't see how float speeds can exceed int > speeds. But considering all of the other points you all have > brought up my suggestion seems to have been short-sited. If your most recent knowledge is of x87 floating point asm, I understand this perfectly. However, a speed and assembly enthusiast should keep himself updated. Best regards, Vesa ############################################################# This message is sent to you because you are subscribed to the mailing list <vst-plugins(a)lists.steinberg.net>. To unsubscribe, E-mail to: <vst-plugins-off(a)lists.steinberg.net> To switch to the DIGEST mode, E-mail to <vst-plugins-digest(a)lists.steinberg.net > To switch to the INDEX mode, E-mail to <vst-plugins-index(a)lists.steinberg.net> Send administrative queries to postmaster(a)steinberg.de ------- End of Forwarded Message

23 years

[linux-audio-dev] midi programming (bulk data on Yamaha TX81z)

by Will Benton

Howdy, all. I've sent a similar message to comp.music.midi and rec.music.makers.synth, but I don't think I'll get many replies. I hope this isn't OT for the list (and that someone here knows the answer!) In any case, I'm trying to write an application that "does stuff" (not necessarily an editor/librarian, but with a small feature overlap) with the user bank and performance data on my TX81z here, and I'm confused about the VMEM bulk data format. 1. Page 74 of the manual states that address 6 (and 16, 26, and 36) is occupied by AME (b6), EBS (b4-2), and KVS (b1-b0) data. However, it also states that KVS data ranges from 0-7, which is clearly impossible in 2 bits. Where's the mistake? Should EBS be bits 5-3 and then KVS as bits 2-0? 2. How would one compute VMEM checksums? Heck, as long as I'm at it, what's the method for computing all of the checksums (i.e. VMEM, PCED, PMEM, SYS, microtune, etc.)? I have looked at the sourcecode for JSynthLib (which, for some reason, doesn't run properly in my environment -- too bad, because it seems to be a good program), but the answers to these questions were not really clear to me from an examination of its TX81z driver. (In its defense, very little bit-twiddling Java code is particularly clear.) In particular, either their checksum implementation is wrong or the TX81z manual is wrong (my money's on the latter). In any case, I'd be glad to hear from anyone with experience doing this kind of junk to the TX81z. It seems that most of the TX81z sysex info available on the net is for real-time control. best, wb -- Will Benton | "Die richtige Methode der Philosophie wäre eigentlich willb(a)acm.org | die: Nichts zu sagen, als was sich sagen läßt...."

23 years

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