Hey everyone --
Sorry about the multiple postings, but I figured what the heck...
I've just put on-line a whole lot of work I've done; papers, pieces,
software, etc. Here's the link for the 2-3 people (beyond my immediate
family) who might be interested:
http://music.columbia.edu/~brad/
There's a fair amount of unix/linux work scattered throughout, including
the big "My Music Book" thing I did a few years ago.
Hope you enjoy this!
brad
> I'm hoping that you're thinking of a realtime display, in which the
> peaks roll off to create a true waterfall effect.
Baudline (http://www.baudline.com) is a fantastic viewer that does fft
cascade. I've used it for a couple of years, and it is great for figuring out
how different sounds "work", and it has an oscilloscope-type display as well.
Cheers,
Jason Downer
Hello.
I finally started making my pet music project and realized I need a
drum synth to make some cool sounds. psindustrializer is good but also
need some tr-909-style sounds. I remeber from my old windoze days I
used a nice piece of software called Stomper. Does anybody know any
software for linux with comparable capabilities? Or we need to write
one?
Stomper does not work under wine :(
Thanks.
Hello.
I had a couple of articles on drum synths. Check
ftp://ftp.funet.fi/pub/sci/audio/devel/lad/drumsynth/
I built the circuit in a00*.jpg at the time when this article
was fresh. The article b00*jpg mentions an earlier article.
I will check that out at library.
Hmm.. I coded a drum synth for Commodore VIC-20 at the time.
VIC provided an audio chip with three oscillators, noise,
and a common volume if I remember correctly. What I did was to
modulate osc pitch and volume parameters with a fast and accurate
(compared to Basic) assembly code. The drum sounds were assigned to
the keys. This was about 1984, inspired by Yamaha's digital RX drum
synths, not by analog drums.
Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software
http://plugin.org.uk/ladspa2/
Removed the :logarithmic hint, I agree with Paul, its not
fit-for-purpose as specified.
I'm now using the DOAP schema (http://usefulinc.com/doap) instead of Dublin
Core for software information, much more appropriate.
Fixed a load of typos in the schema and examples.
Dave R. doxygen-ised the .h and added some text about choosing URIs.
I removed the references to run_adding() (I think I got them all).
- Steve
Almost two years ago at the LA conference a bunch of us agreed that
something need to be done to improve LADSPA, and on the approximate
direction it should take.
Anyway, I finally got round to making a sketch plugin and .h file:
http://plugin.org.uk/ladspa2/
The .ladspa2 plugin is a "bundle", ie. a directory with all the data the
plugin needs in it. This idea is nicked from OPENSTEP. I'm not 100%
convinced it's a good idea, but I think it makes sense for plugins.
The dsp core (amp.c) is just a LADSPA 1.1 plugin with all the fixed data
fields taken out, and a URI field added, to allow for working
identification. I also dropped the runAdding method, as I dont think it
is used enough to justify the effort of supporting it. The plugin is
untested, but it compiles and nm reports sane contents for it.
The data is in the amp.ttl file (it's in Turtle
http://www.dajobe.org/2004/01/turtle/ an easy to hand-write RDF syntax).
We could mandate a particular syntax for the spec.
There's a shell script (show-data.sh) which, if you have raptor and rasqal
installed will do something similar to what analyseplugin does for LADSPA
1.x, but it's very crude.
Overall I think this is a much better approach than LADSPA 1.x, it has
usable identifiers, a clear route for extensions without compatibility
problems and each plugin is quite a lot simpler.
- Steve
Hi,
It is widely felt that the LADSPA plugins are becoming difficult for
average users to manage due to the number of available plugins and the
many different packages available.
There is also a problem that developers face when managing different
plugins as UniqueIds are not assigned by a central authority so it is
possible that there can be double ups.
I am volunteering my time to code a new web portal with the express
purpose of providing a single place to get all known LADSPA plugins and
packages. It will be hosted at ladspa.linuxaudio.org. it will also serve
as a central automated authority for assigning UniqueIds.
I would like to use this thread to discuss the finer details of the
functionality of the site and how to make a package of all Plugins which
will also be hosted on the site. The site will be run with a MYSQL DB. I
intend to code it in AJAX style with a PHP+MYSQL backend.
It will be a fully automated web portal and administrative interface.
Here are the features:
---------------
- Add new plugin/s via batch or manual upload/insert
- Automated assigning of UniqueIds
- Create complete package tarball automatically
- Administrative interface for managing plugins and developer profiles
etc...
- User friendly frontend with accessibility: css, java, php, html, xml
----------------
I will appreciate your indepth analysis of the best methods to allow the
above features for the portal. At this stage the most important points
to discuss are how to manage the plugins efficiently and with minimal
overhead and assigning UniqueIds automatically.
Cheers.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.comHttp://www.djcj.org/LAU/guide/ - The Linux Audio Users guide
========================================
"Anything your mind can see you can manifest physically, then it will
become reality" - Macka B
Steve Harris:
>
> Several people have suggested that LADSPA is not a great name for what we
> are calling LADSPA 2. Reasons for this include:
>
> The L, it's not really linux specific, and though /we/ know that its the L
> of LAD, its not obvious to people outside.
>
> The S, it ain't really going to be simple. For someone like me, who is
> neck deep in triples on a daily basis, 2.0 seems like the paragon of
> simplicity, but I can imagine 2.9 being quite a beast.
>
> LADSPA, (pron. ladspuh?) is a bit of a mouthful, and not exactly catchy.
>
> 2.0, it's not going to be obvious to all users that 2.0 and 1.0 are binary
> incompatible. I'm not sure everyone thinks in major and minor revisions.
>
> So, with some trepidation I suggest that we think about naming, with the
> proviso that if we haven't reached consensus by May 10th we default to
> LADSPA 2.0, and live with the pain.
>
I don't agree about taking away the "L". Ladspa is not linux-specific, but
it has certainly originated from linux, and has the best support in
linux software. If linux dissapears before the ladspa format, we can at
least still remember linux through the name of ladspa...
Regarding your argumentation about the prononounciation, I think its a bit
anglocentric language-vice. In most other countries (scandinavian,
german, spanish, belgian, dutch, slavic (I might be wrong about some of
these though)), where the "a" is actually pronounced like the round "ah"
(and very short in this case), and you don't have to move the mouth that
much as in english (and especially in american english), "ladspa" sounds
really cool and is not very difficult to say. A good solution to this
problem would be if the english speakers started to allways say the more
common rounder "ah" instead of "a", not only for ladspa, but for all
acronyms.
I think the argument about S is valid enough though, but not a good enough
argument to change a name we all have learned and love(?). As an
alternative, we can change the meaning of s into something else, like
Super, Second, Sophisticated, System, Steve, Sourcecode, Syntax,
Structure, Success, Superb, Superior. To name a few, well, I'm sure there
are better alternatives.
> ----
>
> My suggestion is that we ressurect the XAP name
> (http://www.google.com/search?q=lad+xap)
> It stood for Xap Audio Plugin IIRC.
>
> Pros: it's short*, relatively unused** and pronouncable***
>
> Cons: xap.{com,org,net} will have gone long ago (too short), theres a
> small ammount of baggage.
>
I think its too short. Its not cool, and its hard to remember from the
pronounciation.
Hi!
Usually I don't announce new versions of libgig here anymore, but this release
might be of interest for some:
Beside a bunch of bug fixes it now also allows to modify existing and create
new Gigasampler files. If anybody's interested in writing a .gig editor, have
a look at the "gigwritedemo.cpp" example application:
http://stud.hs-heilbronn.de/~cschoene/projects/libgig/#examples
libgig is released under (pure) GPL and as always available on its original
site:
http://stud.hs-heilbronn.de/~cschoene/projects/libgig/
as well as on the LS server:
http://www.linuxsampler.org/downloads.htmlhttp://download.linuxsampler.org/packages/
CU
Christian
P.S. I just restored the old libgig source packages on the LS server, all
other packages will be restored after LAC (that is next week) - I know the
downloads section on LS.org was dead for too long now, sorry!
