I've been looking around for a library to read and write SFZ files,
which is an open sampler format released by Cakewalk:
http://www.cakewalk.com/DevXchange/sfz.asp
Finding none, I thought I might try my hand at writing a library for
this myself, as there is no embedded wave information like with Gig
files. SFZ is simply a text file to be parsed.
Now, I know about writing a good header file, and its associated class,
and all that, but I have no knowledge of how to write it as a dynamic
library. Google searches on every possible permutation have been
worthless to me as well.
I would prefer to write it in C++, as that's what I know, and even then,
not too well, hence why I thought I'd start with something simple like
parsing a text file. If anyone has any advice, recommendations, or
ideas, I'll happily listen and learn. I have yet to think too much about
how the data will be stored in the class, and what methods to make
available to access it, so if anyone knows any best practices there, I'd
really like to know. Consider this a feeler post.
I'd ultimately want this for a future project, which you can guess at by
now.
Thank you for the help!
Regards,
Darren Landrum
Anyone knows a good vector drawing program for Linux ?
Absolute requirements are:
- Lines, arrows, boxes, circles, etc.
- Linewidths and styles, colors, filling.
- Text
- PDF or PS export.
- PNG and JPEG import (no bitmap editing required).
- Accuracy.
I've been using TGIF for years, but I'm more and
more being blocked by its main flaw which is that
it seems to use a unit of 0.2mm internally (in
metric mode) which is orders of magnitude too big.
Tried QCAD and INKSCAPE, both fail basic
requirements (and have other problems).
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
O tu, che porte, correndo si ?
E guerra e morte !
hi there everyone.
i hope this is the right list for this, but i just had a question
about embedded hardware.
if i was wanting to develop a small (up to around 20cm square) device
using an embedded linux setup, is there any high end (pro quality jack
compatible) audio devices that are easily attainable? basically
something like a high end adc/dac for minipci or something similar i
suppose.
anyone on here know?
thanks
porl
ps. should this be posted to the users list instead, since i suppose
it doesn't have a direct connection to linux development?
I have some doubts, as both host and plugin programmer, regarding the text
encoding that should be used for Ladspa v1 metadata fields. Is there any
convention? Utf8? Is it limited to plain ASCII? Which fields are restricted
and which are not?
I supose that unicode is supported in some way as many 'makers' have weird
signs on their name but the header-documentation does not provide any answer
to that.
David García Garzón.
Fons Adriaensen:
>
> Inkscape lookd more and more as some GUI interface
> to Cairo. ATM I can write the Cairo code a lot
> faster than using the GUI...
>
I was just about to suggest writing Cairo code. :-)
pgf/tikz is probably faster than programming cairo
though. But what would be really nice would
be a programming interface for pgf/tikz.
Fons Adriaensen:
>
> Anyone knows a good vector drawing program for Linux ?
>
> Absolute requirements are:
>
> - Lines, arrows, boxes, circles, etc.
> - Linewidths and styles, colors, filling.
> - Text
> - PDF or PS export.
> - PNG and JPEG import (no bitmap editing required).
> - Accuracy.
>
> I've been using TGIF for years, but I'm more and
> more being blocked by its main flaw which is that
> it seems to use a unit of 0.2mm internally (in
> metric mode) which is orders of magnitude too big.
>
> Tried QCAD and INKSCAPE, both fail basic
> requirements (and have other problems).
>
>
Maybe pgf / tikz would be useful?
http://www.ctan.org/tex-archive/help/Catalogue/entries/pgf.html
Hello, I had a great performing linux audio setup until I had to move to
a newer kernel to get some hardware on a new motherboard to work. Now I
can't seem to get decent performance and thought it might be helpful if
folks could chime in with what versions, etc. they are using with decent
success. In particular I'm having a very challenging time with Linux
Sampler, which I had previously working very solidly but now regardless
of numerous jack/ls version permutations segfaults when I create a jack
driver in ls. Thanks! -Garett
Kernel version? RT patch? Preemption mode? Audio hardware IRQ scheduling
policy and priority?
Alsa version if different from kernel?
Jack version, scheduling policy and priority?
Linux Sampler version (or cvs date), scheduling policy and priority?
hi anthony!
thanks for your reply. i'm cc:ing the list so that others can benefit
from it as well...
Anthony Kozar wrote:
> Hi Joern,
>
> This is just a shot in the dark, but most audio CD tracks have a "lead-in"
> time of 2 or more seconds. CD players will typically count down using
> negative numbers for this time and the track is considered to begin after
> the lead-in. Perhaps one of your drives (the DVD drive?) is reading the
> lead-in as part of the track?
>
> (2 seconds x 44100 samples/sec. x 2 channels x 2 bytes/sample = 352,000
> bytes)
i can rule this out, because although i used both a dvdr and cdr drive
for burning, both cds were read back in using the cdr drive.
any differences must have occured during burning. but since i used the
same toc file and disk-at-once mode, it's unlikely that the lead-in got
interpreted differently in both drives... but you are right, this being
a live cd, i used pre-gaps and non-silent gaps extensively - i'll
investigate some more along those lines.
best,
jörn
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
Hello everybody,
my name is micu and I study computer science at the Dresden University of
Technology. During an internship at the operating systems chair of the
university, I ported ALSA to the chairs operating system DROPS aka TUD:OS
[1,2]. To let ALSA talk to the hardware and provide to it the usual linux
kernel environment DDEKit / DDELinux [3] were used. As a kernel-userland
interface I wrote a very small emulation layer, which makes it possible to
link SALSA-lib [4] against the ALSA "kernel" part.
So right now, we have a somewhat stable ALSA server running in userland on top
of DROPS without changing ALSA or the SALSA-lib source code.
I have been continuing this project within my diploma thesis. The remit of the
thesis can be found here [5]. It is the goal of the thesis to take some steps
towards a truly realtime capable (meaning with time constraints to be
guaranteed) FOSS audio distribution. Here [6] you can see a raw version of my
requirements definition.
The architecture we are going to use is --- how could it be different :) ---
Jack or Jackdmp (with a strong bias towards Jackdmp). To get the mess out of
my head, I wrote a short guide [7] to the Jack source code. It is a pretty
raw version and it isn't finished in any way yet; but I won't work on it any
longer. Nevertheless, it might be helpful to other developers new to Jack.
Therefore, if you will, you may get it under any license you wish
(attribution of the author is appreciated :) to publish and improve it.
Of course, the long term goal of the project won't be met to any extent during
my thesis and I have no idea, if this project will be continued here at the
university. Neither do I know, whether I will have time to work on it
afterwards.
To make a long story short: I would like to ask my first three questions....
so far :)
1.) Do you agree on having a truly real-time capable architecture in the FOSS
audio world would be a really great thing --- and would you say, getting such
a thing maybe could get a (major) goal of the pro audio FOSS community?
2.) Concerning our Jack vs. Jackdmp decision: http://jackaudio.org/ says,
Jackdmp is going to be Jack 2.0. How likely and how soon do you think is this
going to happen?
3.) I guess, there is a very minor bug in the lines 236, 237 of
libjack/driver.c, svn revision 2734: The type castings should be switched.
Thanks a lot in advance and please excuse my bad english :(.
Regards,
micu
BTW: I love Jack and I love ardour --- and therefore I love you :).
==========================================
[1]http://www.realtimelinuxfoundation.org/variants/variants.html#VARIANTS_DR…
[2]http://www.osnews.com/story.php/15814/Introduction-to-TUD-OS/
[3]http://demo.tudos.org/dsweeper_tutorial.html
[4]http://www.alsa-project.org/main/index.php/SALSA-Library
[5]http://www1.inf.tu-dresden.de/~s3418892/task.txt
[6]http://www1.inf.tu-dresden.de/~s3418892/Require.pdf
[7]http://www1.inf.tu-dresden.de/~s3418892/AgttJSC.txt
--
GnuPG: https://www1.inf.tu-dresden.de/~s3418892/micuintus.asc
Fingerprint: 1A15 A480 1F8B 07F6 9D12 3426 CEFE 7455 E4CB 4E80