Dan Mills wrote:
> On Sun, 2009-08-23 at 19:24 +0200, Ralf Mardorf wrote:
>
>> The only useful thing is to
>> have a pre-adjusted meter, that can't be readjusted by the audio
>> engineer.
>>
>
> How do you deal with the annoying detail that there are at least 3
> standard alignments between 0Vu and 0dbFs (EBU, SMPTE and US Radio)? You
> need a calibration tweak to allow you to set the meters to whatever
> standard the rest of your system is aligned to.
>
> Regards, Dan.
I'm very sceptic that meters for studios in the box are in sync with
external equipment. I'm also very sceptic about the quality of measure
accurately for external equipment in any home recording studio, any
semi-pro studio and even some pro studios, were the equipment isn't
checked on a daily basis. Absolute accuracy becomes important especially
if tapes are sent from one studio to the other. The effective value is
sine wave +3dB = 0 and nothing else. Am I wrong?
A short while back I floated some experimental notions involving ZynAddSubFX
on LAU. That was useful, especially Paul D's comments (they always are). I
subsequently posted a patch on the project's Tracker on sourceforge, which
naturally caught the attention of Mark McCurry, currently running the
ZynAddSubFX project.
As far as Zyn is concerned, I do so wish for good things to happen to it in
the future. I suspect there's both lurkers and devs on this list with some
interest in zyn, so with the indulgence of everyone concerned I'm presenting
a thread from Zynaddsubfx-user. I hope Mark doesn't mind, but airing this
here might somehow prove helpful. Hope so.
-------- Original Message --------
Subject: Re: [Zynaddsubfx-user] more on improved jack io
Date: Thu, 13 Aug 2009 19:09:41 +1000
From: cal <cal(a)graggrag.com>
To: Mark McCurry <mark.d.mccurry(a)gmail.com>
CC: zynaddsubfx-user <zynaddsubfx-user(a)lists.sourceforge.net>
References: <4A7E48B3.2030401(a)graggrag.com> <278139b70908121642p78b4a0caw7543afd87e4d8db8(a)mail.gmail.com>
Mark McCurry wrote:
> Cal,
>
> I would like to integrate in your patch into the main branch, as better
> jack and alsa audio are something that is desired, but it does look like
> it currently needs some extra work.
> For the previous patches, they did get out of date before I had too much
> of a chance to integrate them.
> For the previous iteration of this patch, I do believe that I asked
> Harald Hvaal to attempt to integrate some of your work after contacting you.
> He told me that he did email you, but he did not get a response.
>
> In the diff, it looks like you took the changes that you made to an
> earlier version and just diffed it with current code.
> This generates an unreasonable amount of noise to hide the signal.
> There are also a good number of stylistic/superficial differences
> (REALTYPE -> zynsample_t , whitespace differences, Master -> zynMaster ,
> etc) (in my opinion).
>
> If the diff was readable, then it would have a good chance to get into
> the main git branch, but for now it is illegible.
> I apologize for letting it balloon to this size and I am still
> interested in integrating parts into the git code, but it needs to have
> the fat trimmed before that can happen.
>
> --Mark McCurry
> (If you prefer that this discussion occurs on the mailing list, then
> that is fine with me)
>
hi Mark,
As patch reviews go, that one's probably about as naive and shallow as they
come. I do appreciate your mail though, and I've cc'd the user list as
suggested - perhaps a wider audience might help the discussion.
In dismissing "stylistic/superficial differences", I suspect you have no
clue as to why I considered those changes desirable and/or necessary from a
software engineering perspective, as distinct from merely stylistic. From
your review, I also suspect there's been little or no analysis of what it
might take to improve the structure of the audio and midi drivers, and to
have zyn use jack's reported samplerate and buffer size. And no comment
whatsoever on how well or badly I've achieved those goals. Naive in the
extreme.
On the subject of whitespace - the complete absence of whitespace and rational
indentation in the official code is one of the main reasons (but not the only
one) why zyn is in danger of bit-rotting its way to oblivion. Code like that
was normal in 2002, but you'd be hard pressed to get any serious coder to even
look at it today. In my humble opinion, the whole codebase needs the whitespace
issue addressed if the code's to have any future.
I started looking into the zyn code because I needed it to work well and
reliably, which the official codebase does not do. What I've actually attempted
is to take what I consider the latest interesting version of the code (2.4.0,
released by paulnasca) and fix those broken elements that were causing me grief.
I needed jack audio/midi to work well, so I fixed it. I saw alsa audio out as
potentially useful for simple performance, so I added it.
My patch is clearly labeled "experimental", so if anyone else finds it
interesting or useful, then that's cool too. I'm pretty comfortable with what
I've achieved so far. Jack audio is better, jack midi works well although the
structure is far from ideal, or even good practice. I'm surprised you didn't
notice that in your review of the patch. I know how to resolve that, but it's
going to take even more serious restructuring to accommodate it properly. If
and when I manage to get that together, I predict that that too will be
summarily dismissed as just more fat to be trimmed.
I'm also quite comfortable with the fact that my personal goals are way out of
alignment with those of the "official" project. Over some months I've watched
the changes going into git, and I'm less than enamoured with the changes since
paulnasca's active involvement. In moments of melancholy, I do fear the official
codebase is devolving ever so slowly toward becoming just a sad undergraduate
fantasy. Naively sprinkling esoteric abstractions through the code while
blissfully ignoring significant shortcomings in the code isn't likely to
produce anything of value.
Merging my audio/midi driver changes into git wouldn't be a trivial exercise,
but really not all that hard. No offense, but I suspect neither you or Harald
have the necessary skills (yet) to achieve that effectively. I don't see the
current direction of the "official" development effort as interesting, hence
I'm reluctant to engage in any serious fashion.
cheers, Cal
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Zynaddsubfx-user mailing list
Zynaddsubfx-user(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zynaddsubfx-user
On Tue, 2009-08-18 at 07:53 +0000, Michael Chapman wrote:
> On Sunday 16 August 2009 7:17 pm, Jörn Nettingsmeier wrote:
> > michael, there are plans to implement the ACN/SN3D scheme in the LV2
> > plugin standard.
> Excellent news!
> > since it's based on rdf, the question is whether it might feasible to
> > use the URLs for each ACN on ambisonics.ch as unique identifiers (which
> > would be quite elegant and point users right to the relevant
> > documentation).
> Sounds good.
> > however, that would depend on whether you could guarantee stability of
> > said URL space.
> Don't see any practical problem.
> Legalistically the Association will undoubtedly go through
> other officers over the years, but I cannot see any restraint on the
> present Council giving an irrevocable commitment for something that is
> manifestly in the interests of ambisonics.
> I am also (I hope we all are) committed to Tim Berners-Lee
> philosophy of not chopping and changing URLS (his great example is that
> info.cern.ch --to his regret-- became w3.org, without even a redirect ...
> and so the oldest web address in the universe disappeared).
> > a short excerpt of the preceding discussion is quoted
> > below. please maintain the cc: list when replying.
Sounds good.
It's probably a mistake on my part to use your /documentation/ URIs as
the URIs for the concepts themselves anyway. Stable URIs are still good
for all the usual reasons though.
> > The stream descriptions could use them as well if there were URIs such
> > as:
> >
> > http://ambisonics.ch/standards/filetypes/h1v1
> >
> > instead of:
> >
> > http://ambisonics.ch/standards/filetypes/f
> >
>
> None of my business, but if you are going HV, rather than HVP (which I
> don't think I would ...) then Malham Notation (e.gg: "f", "fh") seems to
> me a lot easier ...
Sorry, I meant h1p1. Point being the current scheme doesn't really tie
in with the use of (H,V) notation elsewhere on the site, and doesn't
extend to higher orders very nicely. Nitpicks, anyway.
> A redirect from http://.../h1v1 to http://.../f would not be impossible.
> Would that be anyuse?
>
> > or better, http://ambisonics.ch/standards/streams/f if I can nitpick :)
> >
>
> Likewise a redirect from http://.../filetypes/... to
> http://.../streams/.... though if we are nitpicking I prefer
> http://.../signal_sets/... ;-)>
>
> Not sure about the 'ethics' of littering the name space with redirects and
> welcome comments from anyone who has thought more about this than I have.
> Not least how does one redirect: presumably a 303 ("see other") is
> preferable to a 301 ("moved permanently")? But I've not done that many /
> thought that much about redirects in my life .... ;-)>
Probably not worth changing. Also, hyphens in URIs are prettier :)
> Please accept the gratuitous comments above as that. Seems silly not to
> throw in my bits of experience at this early stage.
> The bottom line is though, that this is your project and we are willing to
> help as much as we can with whatever _you_ want.
I'm just acting as RDF scribe, really. I defer to you folks who
actually know a lot about ambisonics completely. Aside from a very
helpful ambisonics for dummies sort of intro from Fons, I'm clueless :)
Thanks,
-dr
Is there any existing 'standard' for the order of channels for
higher-than-stereo multi-channel streams?
I'd assume this would be defined for interleaving or something, though
that's not what it's needed for: I think the port groups extension
should specify an order for all the channels of the various types of
group. Though this isn't necessary useful in the normal case (ports are
separate ala LADSPA), with this replication stuff and presumably other
things the host and plugin are going to have to deal with sets of
buffers, and having a predefined standard order for them seems like it
would make life a lot simpler and faster (and not having one seems to
have no benefit).
For example, for discrete non-interleaved 5.1 (using a full channel for
the .1) we have 6 channels: left, center, right, rear left, rear right,
LFE (see http://lv2plug.in/ns/dev/port-groups#FivePointOneGroup)
What order should these be passed in? Any existing practices?
Thanks,
-dr
Hi all,
A bugfix version of TAP-plugins has been released. It aims to fix:
* problems on 64-bit (silence in EQ, etc)
* denormal problems
* GCC compiler warnings
* uninitialised variables (detected via Valgrind)
Thanks to Damon Chaplin for spotting the issues, working on the
solution and preparing a patch.
TAP-plugins is hosted on SourceForge, please visit:
http://tap-plugins.sf.nethttp://sourceforge.net/projects/tap-plugins/
There is no new functionality in this release. If 0.7.0 works perfectly
for you, there is no need to upgrade.
Enjoy,
Tom
Hello all,
I have an ardour mixer strip with 4 input and 2 outputs,
and insert (post-fader) a plugin which has 4 inputs (A,B,C,D)
and two outputs (X,Y).
The signals at the output of the strip seem to be
X + C + D and Y + C + D instead of X and Y.
Is this 'documented behaviour', and if yes what
purpose does it serve ?
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
> David Robillard -
> Anyway, ...replication in basic form is pretty straightforward: the host
> needs a way to pass a 'replication factor' to the plugin. This raises
> a
> few obvious questions:
>
> - Should changing this at run-time be possible? This is more useful
> with polyphony than with replication for multi-channel purposes. This
> raises nasty realtime issues, but since buffer allocation is the host's
> problem and a clever host could possibly do it, I think the spec should
> make this possible. Maybe there are problems with internal plugin data
> that needs to replicate as well but in a non-realtime way though?
I have written plugins that support port replication. In my case they
*appear* to do so in realtime, but don't actually.
The host re-instantiates a replacement (with the extra ports), and the
same parameter settings, then inserts the replacement in the graph 'swapping
out' the old instance (and destroying it). This happens pretty darn fast -
milliseconds.
The advantage is a minimal, simple API - when a plugin in created it
queries it's 'replication factor' and adjusts itself accordingly. I don't
need to support changes 'on the fly' while the plugin is processing audio
(which could be difficult to perform within the constraints of realtime
operation (without memory allocation etc).
So you can avoid the nasty realtime issues, yet easily support run-time
flexibility.
Jeff McClintock
This is rather off-topic for this list, but I know that some
developers here have a warped interest in this sort of thing.
Dataquay is a free open source library that provides a friendly C++
API for the popular Redland RDF data store using Qt4 classes and
containers.
http://breakfastquay.com/dataquay/
Dataquay is intended to be simple to use and easy to integrate. It is
principally intended for use in Qt-based applications that would like
to use an RDF datastore as backing for in-memory project data -- that
is, data being edited by the user, such as points and their properties
in a graphical editor -- to avoid having to provide application
data-specific file I/O and to make it easy to augment the data with
descriptive metadata pulled in from external sources. Dataquay is also
intended to be useful for applications whose primary purpose is not
related to RDF but that have ad-hoc RDF needs for metadata management.
Dataquay is similar in concept to the Soprano library
(http://soprano.sourceforge.net/), but smaller, less sophisticated,
and with BSD rather than LGPL licensing.
Please see the website for more information, downloads, and caveats.
Chris
Hello,
I released a new free open source application under GPL3:
contrOSC is a middleware to bridge hardware DAW midicontrollers to OSC
(Open Sound Control) enabled software like PD, CSound or SuperCollider,
so you can easily create patches which communicates with the devices.
The first one is the C4 by MACKIE (tm).
Demopatches for PD and CSound are included, the OSC commands are
documented in the manual PDF.
http://controsc.sourceforge.net
Dependencies are
- QT 4.x
- liblo for OSC
- alsaseq for Midi
So far only sourcecode release.
Cheers,
Malte
--
----
media art + development
http://www.block4.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Rui et al,
I just found that recent kernel development (merging IRQ threads into
mainline) breaks the "rtirq" setup script. Basically rtirq does nothing.
The command to get the PID
PIDS=`ps -eo pid,comm | egrep "IRQ.${IRQ}\$" | awk '{print $1}'`
(rtirq line 120) does no longer work since the IRQ process names have
changed.
I've quickly changed it to
PIDS=`ps -eo pid,comm | egrep "irq\/${IRQ}-" | awk '{print $1}'`
and it sets the priorities again, but that's not correct since it also
raises priority of other drivers on the same IRQ..
Similarly `rtirq status` returns nothing. I've checked with:
`ps -ewo pid,class,rtprio,ni,pri,pcpu,stat,comm --sort -rtprio`
instead.
It looks like a new set of regexps for rtirq is in order ;)
This is
Linux soyuz 2.6.31-rc5-rt1.1 #1 SMP PREEMPT RT Wed Aug 5 23:06:21 CEST
2009 i686 GNU/Linux
# ps -eo pid,comm | grep -i irq
4 sirq-high/0
5 sirq-timer/0
6 sirq-net-tx/0
7 sirq-net-rx/0
8 sirq-block/0
9 sirq-tasklet/0
10 sirq-sched/0
11 sirq-hrtimer/0
12 sirq-rcu/0
149 irq/9-acpi
495 irq/14-ata_piix
496 irq/15-ata_piix
506 irq/16-yenta
526 irq/12-i8042
527 irq/1-i8042
1418 irq/8-rtc0
1428 irq/19-ehci_hcd
1446 irq/16-uhci_hcd
1447 irq/17-uhci_hcd
1450 irq/18-uhci_hcd
1452 irq/19-uhci_hcd
1544 irq/29-iwl3945
22591 sirq-high/1
22592 sirq-timer/1
22593 sirq-net-tx/1
22594 sirq-net-rx/1
22595 sirq-block/1
22596 sirq-tasklet/1
22597 sirq-sched/1
22598 sirq-hrtimer/1
22599 sirq-rcu/1
22609 irq/17-HDA Inte
22610 irq/17-ohci1394
22952 irq/16-i915@pci
22968 irq/28-eth1
Yes I'm also baffled at the high PIDs for IRQs. I hazard a guess that
those are a result of a suspend/resume cycle; and I'll check later if
the chrt settings do persist after a suspend/resume.
so long,
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkp7AfMACgkQeVUk8U+VK0LBZACfUeRxyGBf5rpmMvlurTFxKRis
zk0An2QFd07wyg5wHRZXY0MJjD9dESnv
=JLI3
-----END PGP SIGNATURE-----
