linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas

Re: [Linuxsampler-devel] new site for beta testing

[Alexandre P. <av...@al...>]

On 17 Jun 2003 20:57:33 +0200
Josh Green <jg...@us...> wrote:

> already supports loading DLS2. Also re-writing many of the widgets
> (piano, key/velocity splits, sample viewer) to use the GnomeCanvas

Do you use GtkWaveForm widget?

-- 
Alexandre Prokoudine
ALT Linux Documentation Team
JabberID: av...@al...

Re: [Linuxsampler-devel] developers list on new site(was: new site for beta testing)

[Marek P. <ma...@na...>]

> Looks nice :) Perhaps I should be added to the developers list? 

Ok. Anybody else who wants to be listed?

Marek

Re: [Linuxsampler-devel] new site for beta testing

[Josh G. <jg...@us...>]

On Tue, 2003-06-17 at 21:02, Marek Peteraj wrote:
> Hi all,
> 
> it's been a while, here's some news, i've done a completely new & html4t
> validated website for LinuxSampler, you may want to check it out here:
> 
> http://www.pleasewipeyourfeet.com/webtest/linuxsampler
> 
> Here's a screenshot of the webpage:
> 
> http://www.pleasewipeyourfeet.com/webtest/linuxsampler/linuxsamplerweb.jpg
> 
> Please report problems you encounter. Any comments appreciated.
> 
> Steve: i can remove that 'dsp guru' if you wish :)
> 
> 
> Marek
> 
> 

Looks nice :) Perhaps I should be added to the developers list? I'd like
to try and contribute as far as instrument patch loading/saving
technology with libInstPatch and perhaps as a frontend with Swami
(http://swami.sourceforge.net). Cheers.
	Josh Green

P.S. Still plodding along with Swami/libInstPatch DLS2 etc development.
Its a lot of work, so it will continue to take a while as long as I'm
the only one working on it, hint hint :) Currently lost in the task of
making the Swami GUI pluggable enough to support multiple patch formats,
although libInstPatch already supports loading DLS2. Also re-writing
many of the widgets (piano, key/velocity splits, sample viewer) to use
the GnomeCanvas (which doesn't actually depend on Gnome BTW), which will
allow for more flexibility (overlaying different controls on the same
canvas) and better handling of scaling (piano at any size).

[Linuxsampler-devel] new site for beta testing

[Marek P. <ma...@na...>]

Hi all,

it's been a while, here's some news, i've done a completely new & html4t
validated website for LinuxSampler, you may want to check it out here:

http://www.pleasewipeyourfeet.com/webtest/linuxsampler

Here's a screenshot of the webpage:

http://www.pleasewipeyourfeet.com/webtest/linuxsampler/linuxsamplerweb.jpg

Please report problems you encounter. Any comments appreciated.

Steve: i can remove that 'dsp guru' if you wish :)


Marek

[Linuxsampler-devel] Linux speaks Akai (2nd try)

[Christian S. <chr...@ep...>]

Hi!

My first mail did not pass the mail distributor, because it was a bit
too large due to the patch. So now I have uploaded the sources for the
linuxed libakai:

	http://stud.fh-heilbronn.de/~cschoene/projects/libakai/libakai.tar.bz2 
	(19k)

These are the complete sources, not a patch. It's very small anyway.

And to make it a bit more covenient for you to get into it, I made a
small UML diagram to give you a quick overview. I just mentioned the
parts, methods etc. which are interesting from the aspect of actually
using the library. Parts which are considered to be interior or not to
be used by you are not shown here:

	http://stud.fh-heilbronn.de/~cschoene/projects/libakai/libakai.ps 
	(38k)

I created it with TCM (http://wwwhome.cs.utwente.nl/~tcm/). Feel free to
add or correct things:

	http://stud.fh-heilbronn.de/~cschoene/projects/libakai/libakai.ssd 
	(30k)

To test the library:
	- uncompress sources
	- if your machine uses big endian, set it in 'include/config.h'
	- 'make' it
	- insert Akai CD ;)
	- run the 'examples/DeviceAccessTest/devaccesstest' binary, which
	  should prompt you the contents of the Akai CD after a couple of
	  seconds

I did not care about the other example program, so it won't compile.

CU

[Linuxsampler-devel] Fw: [linux-audio-user] Linux and hardware samplers

[Alexandre P. <av...@al...>]

I think you mght be interested...

Begin forwarded message:

Date: Thu, 17 Apr 2003 20:02:42 +0100
From: James Greenwood <ja...@uk...>
To: lin...@mu...
Subject: [linux-audio-user] Linux and hardware samplers


Hi,

I want to get Linux and a hardware sampler talking to each other
more effectively.  Specifically the following:

  1. Transfer individual samples between the PC and sampler
  2. Access and back up project files saved by the sampler
  3. Possibly create a hard-disk partition in the PC which the
sampler
     sees as a SCSI drive

The sampler is an Emu ESI-2000 and the interfacing would probably
have to be via SCSI because that's all it offers.

For the 1st aim, I did find out that the sampler supports SMDI, a
protocol for transferring samples over SCSI supported by various
sampler manufacturers including Emu and Yamaha.  Is there any Linux
end-user software that implements this protocol?  Or another way of
doing it?

The only Linux software I have found so far that supports SMDI is
OpenSMDI, which implements the SMDI protocol as a free shared
library for Linux and Windows.  From what I can see there is no
front-end on the Linux version:

     http://home.t-online.de/home/chrisnowak/opensmdi/

If there is no alternative, I wonder how hard it would be to create
a simple command-line interface using this?

For the 2nd aim I want to read ESI's file system to access
individual projects or 'banks'.  Currently, all I've managed to do
is save banks to Zip disks, and then use the Unix 'dd' command to
make images of entire Zip disks.  But I can't mount the Zip disks
(or disk image files) from Linux, or access individual files or
'banks' within them, because the sampler uses a propietary file
system. 

I believe aims 1 and 2 are both necessary because the SMDI protocol
is fairly limited in the sample parameters it supports, so in order
to capture all parameters (such as filter settings) and cleanly save
whole projects in one go, you have to use the sampler's 'Save Bank'
facility rather than transferring individual samples.

So is there any Linux software that can read this proprietary file
system? The only free (as in beer) software I have found is a
Windows program called ESi-Win.  Apparently it lets you transfer
individual samples over SCSI to and from ESI samplers as well.

    http://www.simplydata.co.uk/ESi-Win/

This software actually solves both aims 1 and 2, but it's
Windows-only.  I
briefly tried to run it under Wine, but it didn't work straight
away.  Has
anyone got it working under Wine?  Has anyone seen it running at
all?

Both OpenSMDI and ESi-Win seem to be projects that progressed to a
reasonably functional alpha or beta level but are no longer
maintained -
presumably because their authors sold their samplers.  I'm beginning
to
reluctantly wonder if I should do the same... although it seems a
shame to
do so purely because of issues with file formats etc.

Anyway the final problem arises because, even if I solved all the
above, I am still reliant on the Zip drive to save and restore banks
directly from and to the sampler.  This is not good from the point
of view of reliablility and cost, especially as I undertand Iomega
don't make the SCSI version of the Zip drive any more.

To solve this without buying an expensive SCSI hard drive, I
wondered if it is possible to create a partition on an IDE drive in
the PC that the sampler sees as an external SCSI drive?  (Preferably
with no possibility of the sampler overwriting other partitions on
the drive ;-) 

The sampler has an option "Ignore SCSI device with ID x", which
according to its manual is intended to allow both a PC and the
sampler to be masters on the same SCSI chain and share a SCSI drive.
 But in the setup they describe, the shared drive is a separate box
in the middle - can it be done without this?

From what I understand about SCSI, doing this would at least require
a SCSI card that has the capability to be 'SCSI target' to another
master device, as well as being a master device itself.  So, for
what it's worth, my SCSI card is an Adaptec 2906 and I'm not sure if
it has that capability or not.

What about other options?  I could get rid of the sampler altogether
- then to get the same number of outputs I'd need to upgrade my
soundcard - but anyway, what Linux software is there that could
replace a hardware sampler while probably retaining a sampler-like
way of working? 

Finally, I suppose I could upgrade the hardware sampler.  I guess
that more modern hardware samplers integrate better with PCs in
general. But are their protocols and file formats any more open and
therefore potentially more inter-operable with Linux, or are you
just as locked in by proprietary formats and protocols as before?

Any thoughts, suggestions, ideas welcome.  I can't be the only
person who's wants to do this!

Thanks
James

-- 
James Greenwood | ja...@uk...

If you put in the work, the results will look after themselves
        -- Nick Leeson's mother


-- 
Alexandre Prokoudine
ALT Linux Documentation Team
JID: av...@al...

[Linuxsampler-devel] Re: Linux speaks Akai

[Sebastien M. <me...@me...>]

Christian Schoenebeck wrote:

>Hi everybody!
>
>It took a bit longer than I expected it will, but I finally finished to port
>libakai to Linux.
>  
>
Hi Christian!

Pretty cool news :) !

>To use it:
>	- get current cvs version of libakai from sf.net
>	- apply the patch attached to this mail
>	- 'make' it
>	- insert Akai CD ;)
>	- run the 'examples/DeviceAccessTest/devaccesstest' binary to test
>	  it
>
>Changes:
>	- removed ngl dependency
>	- added code for Linux to search and access the akai data track
>	- adjusted Make files
>
>If your machine uses big endian, set it in 'include/config.h'. I did not
>care about the other example program, so it won't compile.
>
>Sebastien, I haven't checked the Win and Mac part. Maybe they're broken at
>the moment, though it would be very trivial to fix. But I wasn't sure if
>you're interested to merge the Linux port anyway, so I haven't touched it.
>The Mac part looks unfinished. There are some things I would change there...
>
>CU
>  
>

I'll have a look at the code asap and see if i can easily bridge it to 
ngl for my own uses while keeping your patch. If it's ok i'll merge it 
to the CVS. I would be sad to have to fork it if it can work everywhere 
nicely.

Thanks a lot,

Sebastien

Re: [Linuxsampler-devel] RE: Re: Import of the most common sample formats

[Josh G. <jg...@us...>]

On Wed, 2003-04-09 at 13:14, Steve Harris wrote:
> On Wed, Apr 09, 2003 at 10:54:22 -0700, Josh Green wrote:
> > Of course. I've written a vocoder LADSPA plugin before (really just
> > adapted someone elses work to LADSPA):
> > 
> > http://www.sirlab.de/linux/download_vocoder.html if you are interested.
> 
> You should publicise this more, I've had lots of requests for a vocoder,
> and I didn't know one existed.
> 
> - Steve
> 

Its linked on the main page at http://www.ladspa.org. I handed the
maintainership back to the author of the original code that I adapted,
so its now on his site. If you wanted to make it a part of your plugin
collection or take over the maintaining of it you could ask him, I don't
think he is doing anything more with it. I agree that it does need more
exposure, for being as cool as it is :)

Where else do you think it should be advertised? Its actually been
around for almost 2 years now (I showed it a little bit at LinuxTag
2001). It is a pretty cool effect, and seems to work well. In theory one
could easily route the output of a soft synth, as the carrier signal, to
it using JACK but I have yet to try this setup. At the LinuxTag I was
using 2 sound cards, one to create the synthesis and the other to record
it and a microphone as the carrier and formant signals, what a pain,
that is thankfully no longer necessary. Real time vocoding is quite
cool, I remember hooking it up to my TV and watching it with vocoded
audio output, he he. Cheers.
	Josh Green

Re: [Linuxsampler-devel] RE: Re: Import of the most common sample formats

[Steve H. <S.W...@ec...>]

On Wed, Apr 09, 2003 at 10:54:22 -0700, Josh Green wrote:
> Of course. I've written a vocoder LADSPA plugin before (really just
> adapted someone elses work to LADSPA):
> 
> http://www.sirlab.de/linux/download_vocoder.html if you are interested.

You should publicise this more, I've had lots of requests for a vocoder,
and I didn't know one existed.

- Steve

[Linuxsampler-devel] RE: Re: Import of the most common sample formats

[Josh G. <jg...@us...>]

On Wed, 2003-04-09 at 10:04, Matthew Williams wrote:
> Gday Josh,
> Sorry for the long time to reply, I've been quite busy lately.
> 

No problem :)

> Are you aware of CPU(currently known x86 P2, P3, P4, and Athlon) denormal
> issues? This article, even though it focuses on a Windows sound app, it
> explains denormal issues and how they affect sound apps on all platforms:
> http://phonophunk.phreakin.com/p4denormal.html
> Another good read on denormal issues can be found here:
> http://music.calarts.edu/~glmrboy/musicdsp/musicdspFAQ.dsp.html#ct13
> 

Sure, but these issues don't really relate to what I'm working on. My
current focus is Swami which does not deal with audio synthesis
directly, but will use other projects instead (such as FluidSynth, or
linuxsampler when it is available).

> Are you aware of the Linux Audio Developer's Simple Plugin API (LADSPA)?
> More details can be found at this website:
> http://www.ladspa.org/

Of course. I've written a vocoder LADSPA plugin before (really just
adapted someone elses work to LADSPA):

http://www.sirlab.de/linux/download_vocoder.html if you are interested.


Adding VST support to linuxsampler is out of my scope of things to do.
If at some point this kind of support is added, I might look into the
instrument format you mentioned. When I did a search for these formats I
did not find any specs though. Seems like this is probably a low
priority at the moment, at least until linuxsampler has something
working and someone decides to try and add VST plugin support.

Perhaps this topic can be re-visited in the future, when things are more
developed. Cheers.
	Josh

[Linuxsampler-devel] RE: Re: Import of the most common sample formats

[Matthew W. <mw...@wi...>]

Gday Josh,
Sorry for the long time to reply, I've been quite busy lately.

Are you aware of CPU(currently known x86 P2, P3, P4, and Athlon) denormal
issues? This article, even though it focuses on a Windows sound app, it
explains denormal issues and how they affect sound apps on all platforms:
http://phonophunk.phreakin.com/p4denormal.html
Another good read on denormal issues can be found here:
http://music.calarts.edu/~glmrboy/musicdsp/musicdspFAQ.dsp.html#ct13

Are you aware of the Linux Audio Developer's Simple Plugin API (LADSPA)?
More details can be found at this website:
http://www.ladspa.org/
You may want to checkout Audacity's(http://audacity.sourceforge.net/)
implementation(source code) of LADSPA as Audacity is released under the
GPL(http://audacity.sourceforge.net/faq.php?lang=en#g1) here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/audacity/audacity-src/src/eff
ects/ladspa/

As for all fxb/fxp bank/preset files, I know that a VST plugin called
HALion(http://www.steinberg.net/en/ps/products/vst_instruments/halion/index.
php?sid=0) reads them. To use a VST plugin, you need a VST host application.
Very briefly you have a midi track with a small section of notes and then
within HALion you open a fxp file and it changes the sound of that midi
track to another instrument. It works in the same way that the 128 General
Midi voices work on a synthesizer.

At the moment VST host applications exist only for Windows and Mac(Audacity
only has Windows and Mac VST plugin support):
http://ygrabit.steinberg.de/users/ygrabit/public_html/vstgui/listhost.html
The VST Plug-in specification was developed by
Steinberg(http://www.steinberg.net/en/). A VST Host application is an
application that can host VST Plugins that have been developed under the VST
Plugin Specification, either by Steinberg or any Third-Parties. They are
really starting to do some amazing things with VST like the VST System Link:
["What is VST System Link?
VST System Link is a system for networking computers using Steinberg Virtual
Studio Technology (VST) software and Audio Stream Input Output (ASIO)
hardware. VST System Link enables the transfer of synchronization,
transport, and audio data between two or more workstations equipped with
compatible software and hardware over standard digital audio cabling systems
such as ADAT, TDIF, AES/EBU, S/ PDIF etc. And because it uses the audio
stream itself, synchronization is completely sample accurate, even across
multiple workstation configurations!"]
More info about VST System Link can be read here:
http://www.steinberg.net/en/ps/products/music_production/cubase_sl_pc/featur
es/system_link/index.php?sid=0

As mentioned earlier the VST Plug-in specification was developed by
Steinberg. They have a VST SDK which can be used to build VST plugins and
VST host applications as well. This VST SDK can be downloaded here:
http://www.steinberg.net/en/ps/support/3rdparty/index.php?sid=0
There is a licence for it which will appear when you try to download the
SDK, however I also recommend reading "Licensing issues & Trademark Usage"
section of the "VST Plug-Ins Formal issues" found here:
http://ygrabit.steinberg.de/users/ygrabit/public_html/vstsdk/vstsdk2.2/html/
plug/intro.html#licence
However as I understand it, it seems that if people want VST host
application functionality support in The LinuxSampler Project then they may
have to download the VST SDK individually in order to build(compile) The
LinuxSampler Project like how Syntopia require you to download the VST SDK
before you can build(compile) the Syntopia VST plugin(more on Syntopia
later). VST host application functionality support in The LinuxSampler
Project could be an optional component that if people wanted they would pass
an option to the configure script as well as download the VST SDK.

So how could you build VST host application functionality into The
LinuxSampler Project? Well there are a few resources. The VST SDK and online
documentation is a good starting point.
Audacity(http://audacity.sourceforge.net/) which is released under the GPL,
would be the next port of call; Audacity supports VST Plug-in effects on the
Macintosh and Windows platforms. I would suggest downloading either the
Windows(http://audacity.sourceforge.net/windows.php?lang=en) or
Mac(http://audacity.sourceforge.net/mac.php?lang=en) version of Audacity and
a VST plug-in(http://audacity.sourceforge.net/plugins.php?lang=en) or two to
have a play and get your head around VST so to speak. You could checkout
Audacity's source code to see how they implemented VST plugin support for
the Windows and Mac version of Audacity here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/audacity/audacity-src/src/eff
ects/VST/
The next thing I would suggest would be "VST MediaAddOn"(source code
available) which implements the VST PlugIn Interface Technology for BeOS. As
I understand, BeOS is a Unix or Unix-like OS so porting and modifying this
should not be too hard. The "VST MediaAddOn" extends the "BeOS Media
Services" and you may want to checkout "Cortex" to help you understand the
"BeOS Media Services". Both the "VST MediaAddOn" and "Cortex" can be found
here(ignore the 5 second ads):
http://mitglied.lycos.de/cell/projects.html

Of course once you have VST host application functionality within The
LinuxSampler Project you would want to test it with some VST plugins. A list
of plugins for BeOS which work with the "VST MediaAddOn" can be found
here(I'm assuming the sources for these can be found and then porting would
need to be done):
http://mitglied.lycos.de/cell/vst_addon/plugins.html
Then there is Syntopia, which is a C++ project for the Windows platform and
is a modular software synthesizer for use with a VST host. Syntopia can be
downloaded from here(source code available, licence unknown):
http://syntopia.sourceforge.net/download.html
Finally there is ZR-3 which is a VST instrument plugin and is released under
the GPL. ZR-3 has plugins for Windows, MacOS, MacOS/X and can be downloaded
here:
http://zr-3.sourceforge.net/

Once you have a few VST plugins then you can download some VST instrument
files. One good site is
Wizoosounds(http://www.wizoosounds.com/cgi-bin/WebObjects/wizoosounds) and
all of their instrument files are commerial but they have a large list of
formats available(AIFF - Stereo, Battery, Cubase VST/SX, EXS24, Giga,
HALion, LM-4, LM4MkII, 5.1(6 Mono AIFF Files). You can find out more
information about each format by clicking on the down arrow on the "all
formats" drop down combo box under "instrument finder" in the left hand
column as well as visiting this page here:
http://www.wizoosounds.com/cgi-bin/WebObjects/wizoosounds.woa/69/wa/page?nam
e=formats_e.shtml&wosid=7n7V7NA1rObz2qTcMhoPZQMSM9V
Another site is
PrimeSounds(http://www.primesounds.com/prime2/samples/home.jhtml), again all
their files are commerial and the list of formats they support are ESX24,
Giga, Halion, Kontakt, Recycle 2.0, SoundFont 2, and can be search used this
page:
http://www.primesounds.com/prime2/samples/advsearch.jhtml?searchType=assoc
Finally there is the Cubase Magic website which has free, shareware, and
commercial VST, AU, and DX Effects and Instruments available for Mac, Mac
OSX, and Windows which can be found here:
http://st2n.com/daw/en/

Finally there are some other good resources on the net about sound.
* Julius O. Smith's home page(http://www-ccrma.stanford.edu/~jos/) which
contains a number of well-written academical papers. The website claims that
is has ~275MB of on-line publications, sound examples, and software. Just
checkout the music courses or the very huge list of "On-Line
Publications"(http://www-ccrma.stanford.edu/~jos/pubs.html) which is found
under the "Selected Works".
* Music and
Computers(http://eamusic.dartmouth.edu/~book/MATCpages/tableofcontents.html)
which is a nice introduction to digital synthesis. Lots of sound examples
and applets.
* Advanced Programming Techniques for Modular
Synthesizers(http://www.cim.mcgill.ca/~clark/nordmodularbook/nm_book_toc.htm
l)
* FAQs on FIR, IIR, FFT filters as well as Multirate and
CORDIC(http://www.dspguru.com/) as well as HOWTOs, Techniques, tricks, and
tutorials. Another great site that dspGuru.

Hoo Roo,
Matthew Williams

------------------
> I sent this email a while ago, but it appears to have bounced. Please
> disregard any duplicate postings, thanks.
>
> On Thu, 2003-04-03 at 08:22, Matthew Williams wrote:
> > http://linuxsampler.sourceforge.net/
> > ["- import of the most common sample formats (WAV, SF2, AKAI, EMU,
> GIG,
> > ecc)"]
> >
> > All VST plugins read all fxb/fxp bank/preset files. I've got a file
> that
> > ends in fxb here:
> > http://wilber.pointclark.net/vst/01_rhodes_suitcase.fxp
> >
> > Will the Linux Sampler Project support fxb and fxp files?
> >
>
> Its the first time I have heard of them, so I can't really comment
> myself, until I have a better idea of what the format looks like. I
> think DLS2, GIG, Akai, and GUS will probably keep us busy for a little
> while, though. I'm adding support for these different formats to
> libInstPatch as well as GUI editing support in Swami (DLS2 and probably
> GIG formats, the others will likely be import only for the time being).
> This is not going to be done overnight, especially with just me working
> on it. I'm having fun though, so no worries and anyone is welcome to
> help speed the process :) Cheers.
>         Josh Green

Re: [Linuxsampler-devel] import of the most common sample formats

[Josh G. <jg...@us...>]

I sent this email a while ago, but it appears to have bounced. Please
disregard any duplicate postings, thanks.

On Thu, 2003-04-03 at 08:22, Matthew Williams wrote:
> http://linuxsampler.sourceforge.net/
> ["- import of the most common sample formats (WAV, SF2, AKAI, EMU,
GIG,
> ecc)"]
> 
> All VST plugins read all fxb/fxp bank/preset files. I've got a file
that
> ends in fxb here:
> http://wilber.pointclark.net/vst/01_rhodes_suitcase.fxp
> 
> Will the Linux Sampler Project support fxb and fxp files?
> 

Its the first time I have heard of them, so I can't really comment
myself, until I have a better idea of what the format looks like. I
think DLS2, GIG, Akai, and GUS will probably keep us busy for a little
while, though. I'm adding support for these different formats to
libInstPatch as well as GUI editing support in Swami (DLS2 and probably
GIG formats, the others will likely be import only for the time being).
This is not going to be done overnight, especially with just me working
on it. I'm having fun though, so no worries and anyone is welcome to
help speed the process :) Cheers.
        Josh Green

[Linuxsampler-devel] import of the most common sample formats

[Matthew W. <mw...@wi...>]

http://linuxsampler.sourceforge.net/
["- import of the most common sample formats (WAV, SF2, AKAI, EMU, GIG,
ecc)"]

All VST plugins read all fxb/fxp bank/preset files. I've got a file that
ends in fxb here:
http://wilber.pointclark.net/vst/01_rhodes_suitcase.fxp

Will the Linux Sampler Project support fxb and fxp files?

[Linuxsampler-devel] Re: [Swami-devel] porting libakai to Linux, libinstpatch integration ?

[Josh G. <jg...@us...>]

On Tue, 2003-04-01 at 00:01, Benno Senoner wrote:
> Hi guys,
> cool that multiple tools exist.
> I'm looking forward for AKAI reading support in libinstpatch.
> 
> But OTOH, I think it would be very handy if someone of you could port
> libakai to linux (or fix that support lib Sebastien talked about).
> It would especially be useful for those like me that experiment with
> the audio engine, since for the beginning I'd like to read AKAI samples
> (at least basic stuff) as easily as possible.
> Of course later the way to go will be using a complete, multiformat and
> flexible library like libinstpatch, but I think for now it would be 
> VERY HANDY if some of you (Christian S., Frank, Sebastien, Paul Kellet, others
> .. ?) could fix libakai so that it works out of the box on Linux.
> 
> comments ?
> 
> PS: I'm just programming a Delta 1010 card, ALSA really rocks :-)
> 
> cheers,
> Benno
> http://linuxsampler.sourceforge.net
>  

If you are just looking for any patch format that has loading support,
you could always use SoundFont support with libInstPatch. Maybe this
would help the developers here get familiar with the API and get some
ideas of what can be improved, etc with libInstPatch as well. As things
are now, libInstPatch is compiled with Swami, but the library can be
used independently of Swami, once installed.

Some example code (note that the loading API will be improved in the
near future):

IpatchSF2 *
linuxsampler_load_soundfont (char *filename)
{
  IpatchSF2 *sf;
  int fd;

  if ((fd = open (filename, O_RDONLY)) < 0)
    {
      fprintf ("Failed to open file \"%s\": %s", filename,
		strerror (errno));
      return (NULL);
    }

  /* this call will look different when loading API is improved */
  if (!(sf = ipatch_sf2_load (fd, IPLOAD_ALL, NULL, NULL)))
    {
      close (fd);
      return (NULL);
    }

  return (sf);
}


After loading a SoundFont in this fashion, all the IpatchSampleData
objects will contain a single IpatchSampleStoreFile which just holds a
location to the relevent sample data in the SoundFont file. A sample
data object can contain multiple stores though, so you could load all of
them into RAM while still retaining the file stores as well.

When it comes to accessing the objects in the SoundFont, there are a
number of ways of doing this. If not in a multi-thread environment, you
can just access the lists and parameters directly. If multi-thread
access to the same objects is desirable, then objects need to be locked
when accessing their lists (IPATCH_ITEM_RLOCK/_RUNLOCK and
IPATCH_ITEM_WLOCK/_WUNLOCK, currently there is no difference between
read or write locking, but in the future there might be) or the somewhat
slower iterator system can be used (makes a duplicate of a list under
lock, aftwards this list can be used at ones own leasure). I'll just
assume single thread access for these examples:

There is a nice function for rendering a patch item (currently
IpatchSF2Preset, IpatchSF2Inst or IpatchSF2Sample objects) into
SoundFont compatible "voices". This comes in real handy when doing
actual synthesis (used in FluidSynth plugin). It looks like this:

ipatch_sf2_voices_foreach (IpatchSF2Voices *obj,
                           int note,
                           int velocity,
                           IpatchSF2VoicesForeachFunc func,
                           gpointer data)

obj is the item to convert to voices.
note and velocity are the MIDI note and velocity of the note event.
func is the function to call with each rendered voice.

The IpatchSF2VoicesForeachFunc is passed a structure containing the
original parameters, plus an array of generators (effect parameters), a
modulator list (real time effect controls) and a SoundFont sample. From
this information a single voice can be created.

Here is an example of accessing samples and manipulating its sample
stores (in this case we are checking each sample to see if it has a RAM
store, if not we create it), essentially loads all samples into RAM:

{
  IpatchSF2 *sf;
  IpatchSF2Sample *sample;
  IpatchSampleStore *store, *ramstore;
  GSList *p;  /* glib single linked list type (forward only) */

  if (!(sf = linuxsampler_load_soundfont ("test.sf2")))
    exit (1);

  /* single threaded direct list access, a no no for MT environments */
  p = sf->samples;
  while (p)   /* loop over SoundFont samples */
    {
      sample = (IpatchSF2Sample *)(p->data);

      /* find the fastest readable sample data store for the sample */
      store = ipatch_sf2_sample_find_store_ref (sample, 0,
                      IPATCH_SAMPLE_STORE_FIND_FASTEST
                      | IPATCH_SAMPLE_STORE_FIND_READABLE);

      /* if not a RAM sample store, create one */
      if (!IPATCH_IS_SAMPLE_STORE_RAM)
        {
          ramstore = ipatch_sample_store_duplicate (store,
                       IPATCH_TYPE_SAMPLE_STORE_RAM, &err);
	  if (!ramstore)
            {
              fprintf (stderr, "Error duplicating sample data: %s\n",
		       err ? err->message : "<No details>");
              exit (1);
            }
        }

      g_object_unref (store);  /* remove our reference from find */

      p = p->next;  /* next list node */
    }
}


Anyways.. Probably writing too much for this email :) I invite anyone
who is interested to check things out, ask questions, make suggestions
etc. I'd like to start to get an idea of whats good and what could be
improved, before things become too dependent. Cheers.
     Josh Green

Re: [Linuxsampler-devel] porting libakai to Linux, libinstpatch integration ?

[Christian S. <chr...@ep...>]

On Tue,  1 Apr 2003 10:01:32 +0200
Benno Senoner <be...@ga...> wrote:

> But OTOH, I think it would be very handy if someone of you could port
> libakai to linux (or fix that support lib Sebastien talked about).
> It would especially be useful for those like me that experiment with
> the audio engine, since for the beginning I'd like to read AKAI samples
> (at least basic stuff) as easily as possible.

Ok, I will do that in the next days, if no one else does it.
 
> PS: I'm just programming a Delta 1010 card, ALSA really rocks :-)

I'm looking forward to multiple channel support, I also have a Delta 1010.

CU

Re: [Linuxsampler-devel] porting libakai to Linux, libinstpatch integration ?

[Marek P. <ma...@na...>]

On Tue, 2003-04-01 at 10:01, Benno Senoner wrote:
> Hi guys,
> cool that multiple tools exist.
> I'm looking forward for AKAI reading support in libinstpatch.
> 
> But OTOH, I think it would be very handy if someone of you could port
> libakai to linux (or fix that support lib Sebastien talked about).
> It would especially be useful for those like me that experiment with
> the audio engine, since for the beginning I'd like to read AKAI samples
> (at least basic stuff) as easily as possible.

Benno,

i think in the meantime it would be sufficient to fetch abrowse from CVS
and use the akai.c code. That should do it.

Marek

Re: [Linuxsampler-devel] porting libakai to Linux, libinstpatch integration ?

[Sebastien M. <me...@me...>]

I think porting libakai to linux would take no more than an evening. 
Removing the ngl dependency (what a pity to remove this fine piece of 
code! ;D ) would require maybe one week at max (counting only the 
evenings).
But I won't do it (well, I'll do the linux port maybe if I get really 
fed up with my others projects one of these days... ;)

Sebastien

Benno Senoner wrote:

>Hi guys,
>cool that multiple tools exist.
>I'm looking forward for AKAI reading support in libinstpatch.
>
>But OTOH, I think it would be very handy if someone of you could port
>libakai to linux (or fix that support lib Sebastien talked about).
>It would especially be useful for those like me that experiment with
>the audio engine, since for the beginning I'd like to read AKAI samples
>(at least basic stuff) as easily as possible.
>Of course later the way to go will be using a complete, multiformat and
>flexible library like libinstpatch, but I think for now it would be 
>VERY HANDY if some of you (Christian S., Frank, Sebastien, Paul Kellet, others
>.. ?) could fix libakai so that it works out of the box on Linux.
>
>comments ?
>
>PS: I'm just programming a Delta 1010 card, ALSA really rocks :-)
>
>cheers,
>Benno
>http://linuxsampler.sourceforge.net
> 
>
>  
>

[Linuxsampler-devel] porting libakai to Linux, libinstpatch integration ?

[Benno S. <be...@ga...>]

Hi guys,
cool that multiple tools exist.
I'm looking forward for AKAI reading support in libinstpatch.

But OTOH, I think it would be very handy if someone of you could port
libakai to linux (or fix that support lib Sebastien talked about).
It would especially be useful for those like me that experiment with
the audio engine, since for the beginning I'd like to read AKAI samples
(at least basic stuff) as easily as possible.
Of course later the way to go will be using a complete, multiformat and
flexible library like libinstpatch, but I think for now it would be 
VERY HANDY if some of you (Christian S., Frank, Sebastien, Paul Kellet, others
.. ?) could fix libakai so that it works out of the box on Linux.

comments ?

PS: I'm just programming a Delta 1010 card, ALSA really rocks :-)

cheers,
Benno
http://linuxsampler.sourceforge.net
 

Scrive Josh Green <jg...@us...>:

> 
> Cool, thanks for the info. Its not chiming in late anyways, since I have
> yet to even start on the Akai stuff. There is still a little bit to be
> done before this. Things are coming together fast now though. It will
> probably only be a few weeks before it will be in a usable state,
> although much bug hunting will need to be done, as the new API for
> libInstPatch and many other things have not been tested thoroughly. I'll
> be sure to notify the list when the new development branch of Swami is
> ready for testing. I'm getting excited, since I've been working on this
> stuff for over 6 months now without seeing any direct results in
> functionality. I think the wait is going to be worth it though :)
> Cheers.
> 	Josh Green
> 
> 
> 


-------------------------------------------------
This mail sent through http://www.gardena.net

Re: [Linuxsampler-devel] AKAI samplelibrary loader is online

[Josh G. <jg...@us...>]

On Mon, 2003-03-31 at 15:48, Frank Neumann wrote:
> 
> Hi list,
> On 27 Mar 2003 19:09:35 -0800
> Josh Green <jg...@us...> wrote:
> 
> [..]
> 
> > Well, it seems a lot of this stuff is done in libakai at the moment. So
> > we can use it as an example and add Linux support.  Linux and other *nix
> > (BSD, OS X, etc) and win32 are the platforms I'm looking to support.
> > Basically anywhere glib/GObject/GTK goes.
> 
> Sorry for chiming in here so late, but you might want to know there is also
> some other code that performs Akai sample format reading, besides the stuff
> by Sebastien and also besides the "abrowse.sourceforge.net" project; look at
> http://www.nal.ics.es.osaka-u.ac.jp/~oosaki/akaitools/index.html for a set
> of Perl(!) scripts that allow to extract data from S1000 CD images.
> This one works better for me than abrowse at this time.
> 
> "Thought you might want to know",
> Frank
> 

Cool, thanks for the info. Its not chiming in late anyways, since I have
yet to even start on the Akai stuff. There is still a little bit to be
done before this. Things are coming together fast now though. It will
probably only be a few weeks before it will be in a usable state,
although much bug hunting will need to be done, as the new API for
libInstPatch and many other things have not been tested thoroughly. I'll
be sure to notify the list when the new development branch of Swami is
ready for testing. I'm getting excited, since I've been working on this
stuff for over 6 months now without seeing any direct results in
functionality. I think the wait is going to be worth it though :)
Cheers.
	Josh Green

Re: [Linuxsampler-devel] AKAI samplelibrary loader is online

[Frank N. <bea...@we...>]

Hi list,
On 27 Mar 2003 19:09:35 -0800
Josh Green <jg...@us...> wrote:

[..]

> Well, it seems a lot of this stuff is done in libakai at the moment. So
> we can use it as an example and add Linux support.  Linux and other *nix
> (BSD, OS X, etc) and win32 are the platforms I'm looking to support.
> Basically anywhere glib/GObject/GTK goes.

Sorry for chiming in here so late, but you might want to know there is also
some other code that performs Akai sample format reading, besides the stuff
by Sebastien and also besides the "abrowse.sourceforge.net" project; look at
http://www.nal.ics.es.osaka-u.ac.jp/~oosaki/akaitools/index.html for a set
of Perl(!) scripts that allow to extract data from S1000 CD images.
This one works better for me than abrowse at this time.

"Thought you might want to know",
Frank

Re: [Linuxsampler-devel] AKAI samplelibrary loader is online

[Josh G. <jg...@us...>]

On Wed, 2003-03-26 at 14:32, Christian Schoenebeck wrote:
> On 25 Mar 2003 22:28:31 -0800
> Josh Green <jg...@us...> wrote:
> 
> > Are you sure Akai patches are distributed as files? I'd like to find
> > this out, because I'm thinking that filesystem and lowlevel device
> > access code really does not belong in libInstPatch. It seems somewhat
> > like a portability nightmare and I wan't to try and keep libInstPatch
> > as portable as possible.
> 
> Yes, I'm sure. There are mostly two file types: sample and program files
> of course, but I also found another type (0x00) now, which I'm not sure
> about what it's purpose is yet. I would bear the sacrifice to lose some
> portability, because I think the user should not be forced to use
> another tool just to copy and convert Akai ROMs to HD.
> 

I'm starting to agree that this kind of code should be in libInstPatch.
Especially since it sounds like these formats often aren't distributed
as files.

> 
> Yes, S1000 has the biggest library in the world. And BTW S2000, S3000
> (XL), CD3000 (XL), S3200 (XL) use all exactly the same format and differ
> only slightly from S1000.
> 

Good to know. This makes things much easier.

> I already started to write some code to read CDs' TOC and extract only
> the first data track. I've not checked it yet, but I think that code
> would be dependent on Linux. But it would also possible to fopen()
> /dev/cdrom directly, so it would be more portable, but on the other hand
> that way you would have to handle the whole disc by yourself and not
> only the interesting Akai data track, so I would prefer the first one.
> 

Well, it seems a lot of this stuff is done in libakai at the moment. So
we can use it as an example and add Linux support.  Linux and other *nix
(BSD, OS X, etc) and win32 are the platforms I'm looking to support.
Basically anywhere glib/GObject/GTK goes.

> CU
> 

Cheers.
	Josh Green

Re: [Linuxsampler-devel] AKAI samplelibrary loader is online

[Josh G. <jg...@us...>]

On Wed, 2003-03-26 at 02:48, Sebastien Metrot wrote:
> Josh Green wrote:
> 
> > 
> > Okay, I just had a look at the code for libakai. The following are some
> > of my thoughts and findings concerning the Akai formats, libakai and
> > libInstPatch. I would like to invite Sebastien to correct me and perhaps
> > clairify what the scope of libakai is. It would be really nice to
> > collaborate on this stuff :)
> > 
> 
> Sure. But as I already explained to Benno I will not be able to help on 
> the linuxsampler because of legal reasons (i'm part of the Team that 
> develops MachFive, MOTU's sampler, and my employer would be concerned 
> about comflict of interests).
> 

Ok, you need say no more.

>

<cut>

> 
> I don't plan to remove the ngl dependency on libakai, mainly because i 
> truly think ngl is a far better framework than any other I allready 
> tried (for what I do anyway). But removing the dependency seems quite 
> doable. I think the only used ngl classes are nglString (encoding aware 
> multipurpose string class) and nglIStream (encoding/endianness aware 
> streaming class that unifies the IO API nicely).
> 
> The actual loading code is really simple and is just a matter of knowing 
>   what to look for and where to look for it.
> 
> What is missing from libakai is the actual interpretation of each 
> parameter (what is linear, what is lorarythmic, etc...). There is a lot 
> of work left about this and you will have to do it if you want a unified 
> API in the patch library. You will face a lot of diferences between all 
> the diferent patch formats available and interpreting them right often 
> proves to be a pain as Bernard Chavonnet discovered some years ago :).
> 

Yeah, there is a lot of nice features in the GObject library that allow
for parameter specifications. I'm thinking of implementing the Akai
format directly in libInstPatch, rather than using an external library
such as libakai. Much of whats in libakai has to be worked into the
current libInstPatch framework, and so I don't think it makes much sense
to depend on it. I haven't actually looked at ngl, but GObject/glib is a
good platform for what I'm doing. Would you want me to add your name to
the Authors file if I used libakai as example code? Or perhaps just
credit libakai?

> 
> Sebastien
> 

Cheers.
	Josh Green

[Linuxsampler-devel] GUI stuff

[Florian B. <fl...@ar...>]

Hi,

just want to add some words to the GUI stuff (though I know this is no
current topic :-) ).

From: Marek Peteraj <ma...@na...>
> The reason why i'm proposing this is, that a good sampler
> needs real eye-candy too ;) But it's not just pure eye-candy,
> this adds a whole lot of functionality as well, Halion and Mach5
> being the best examples.

Well, I have used Halion for some commercial productions, and I really
do not like it. It leaves the impression of some quick hack. :-) And I
do not think the GUI is a good one - the only thing I liked about it
was the drag=B4n=B4drop of samples into the Halion window. But after all
this one should not be an example of a "functional" tool. That=B4s why
I=B4m here, guys ;-).

> But we really should derive from the look&feel of other pro
> samplers in this regard.

Only if it doesn=B4t mean to copy their weaknesses. By the way, I think
that too many GPL apps simply copy the screwed interfaces of commercial
tools, but that is another story...

From: Josh Green <jg...@us...>
> But from my perspective the GUI interface
> is secondary, and one can have multiple looks & feels :)

I think this is the best way to go.=20


Greets to all,

     Florian Berger, Leipzig, Germany

[Linuxsampler-devel] Re: AKAI samplelibrary loader is online

[Paul K. <pau...@md...>]

> From: Christian Schoenebeck <chr...@ep...>
> 
> I'm just curious if he solved the Teledisk problem. As some Akai
> libraries seem to use this odd "Teledisk" format and I was not able to
> find any information about it.


There isn't much information out there...  but people are still working
on it, as TeleDisk was used for more than Akai formats:

  http://home.earthlink.net/~will_kranz/wteledsk.htm
 
 TeleDisk only works for floppy disks, so conversion from TeleDisk format
to either an Akai disk image or individual Akai files should probably be
done in an external utility rather than supporting .TD0 directly as a 
file format...


> The way I'd like to see things, is that an external utility is used to
> rip the instruments off of different medias and convert them to files
> that can then be imported using libInstPatch. Can one find Akai patches
> on the internet for example? What format would they most likely be in?

Creamware used individual Akai S1000 format files, calling the samples
".S" and the programs ".P".  FMJsoft AWave also supports this format but
I don't know of anyone else who does.  But mostly, image files of whole
Akai CD-ROMs are used (either S1000 or S3000 format).

The Akai S5000 onwards use .WAV and ".AKP" program files on a DOS disk, 
so you do see individual files being distributed - but there are far more
S1000's and S1000 compatible devices around, so S1000 and S3000 are the
formats to concentrate on.


> I have some S2000 format zip disks sitting in my desk draw. From what I
> remeber its very similar to S3000 format, but I dont know if its identical.

Yes, S2000 is the same format as S3000/S3200.



Paul.

_____________________________

  m a x i m | digital audio

    http://mda-vst.com
_____________________________

Re: [Linuxsampler-devel] AKAI samplelibrary loader is online

[Christian S. <chr...@ep...>]

On 25 Mar 2003 22:28:31 -0800
Josh Green <jg...@us...> wrote:

> Are you sure Akai patches are distributed as files? I'd like to find
> this out, because I'm thinking that filesystem and lowlevel device
> access code really does not belong in libInstPatch. It seems somewhat
> like a portability nightmare and I wan't to try and keep libInstPatch
> as portable as possible.

Yes, I'm sure. There are mostly two file types: sample and program files
of course, but I also found another type (0x00) now, which I'm not sure
about what it's purpose is yet. I would bear the sacrifice to lose some
portability, because I think the user should not be forced to use
another tool just to copy and convert Akai ROMs to HD.

> that can then be imported using libInstPatch. Can one find Akai
> patches on the internet for example? What format would they most
> likely be in?

I've only seen images so far. And I don't think you will find something
else. Ok, except S5000 / S6000, as they use FAT fs, and wav files for
samples.

> What revisions of the Akai formats are most desirable to support? Here
> is what I currently have:
> 
> S900/S950
> S1000
> S3000
> MPC-2000
> S5000/S6000
> 
> From what I have heard on this list S1000 is the most popular?

Yes, S1000 has the biggest library in the world. And BTW S2000, S3000
(XL), CD3000 (XL), S3200 (XL) use all exactly the same format and differ
only slightly from S1000.

I already started to write some code to read CDs' TOC and extract only
the first data track. I've not checked it yet, but I think that code
would be dependent on Linux. But it would also possible to fopen()
/dev/cdrom directly, so it would be more portable, but on the other hand
that way you would have to handle the whole disc by yourself and not
only the interesting Akai data track, so I would prefer the first one.

CU