Hi everybody, I'm new to the list. Wassup :)
I have a question regarding liblv2-gui. On the site
(http://ll-plugins.nongnu.org/liblv2-gui.html) there are warnings all over the
place about how the lib is not compatible with rev 3+ of LV2. I searched the
archives of this list and Google, but to no avail, so I'm asking: is there a new
version of this toolset in the works? One that is fully compatible with the
latest version of LV2? I'm enjoying the work that Mr. Luthman has put into this
toolset and would like to continue using it for my current project.
Thanks,
Michael Bechard
Alex,
clearly mentioning the project you forked is just good manners of the
kind that should be expected among civilized people.
Your overreaction to Paul's mail is one hell of an ugly sight.
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/
Version 1.2 of IR, an LV2 convolution reverb plugin has just been released.
This release is the result of many hours of stress-testing, and corrects some
small but unpleasant problems you may have run into while using an earlier
version. IR 1.2 is intended to be production quality software you can rely on.
Please do upgrade to this version.
Changes:
* fix ir.ttl typo: "doap:license" instead of "doap:licence"
* visual feedback of the progress of resampling operations
* resampling operations are interruptible; you can no longer crash
the plugin by deleting it while resampling a long impulse file
* correct GTK2 version requirement and check it in the Makefile:
at least GTK 2.16 is needed
Source code is available from the usual webpage:
http://factorial.hu/plugins/lv2/ir
I wist to thank everyone who provided me with valuable feedback.
Have fun,
Tom
For some reason, gmail has stopped delivering my LAD messages, so
apologies if this reply isn't working correctly...
I'm attempting to run, in general, a 128 sample buffer (frames per
fragment). There is a lower latency mode though which is 64 samples.
I have two fragments. Maybe if I want to do this I should be using
three at least or make 128 the minimum.
But I'm a little confused at the lack of ins and outs being linked.
For a full duplex loop, I'd have to have the input before I can
process output for example, so I don't see how that works unless I
just ignore input requests from ALSA if I am not yet ready to receive.
I'm defining "ready to receive input" as the time after I run my
processing loop and then get a POLLOUT request. However, when I
ignore POLLINs like this, it seems like ALSA immediately POLLINs again
and I wind up with something like 50,000 polling requests handled in a
second, which drives the CPU usage through the roof.
>the in & out are not linked in any way as far as ALSA is concerned
>(even though they may be at the h/w level).
>a 64 sample buffer (not period) is very, very small. you need very
>tight code and a well configured machine to operate like this. what
>period size and/or number of periods are you attempting to use?
>> Hey, I've been having a lot of trouble with ALSA and processing input
>> in a full duplex loop, and I was wondering if anyone here had any
>> insight. I'm using the ALSA poll file descriptor method with the mmap
>> routines. Typically, my processing loop is blowing past the poll
>> statement with input requests (POLLIN), causing the CPU usage to go
>> off the charts as it's basically looping as fast as it can go.
>>
>> Now, I'm handling the inputs in a way that might not be correct.
>> Often, ALSA is saying that the available frames is 1.5 times my buffer
>> size (e.g., I set a 64 sample buffer and ALSA offers me 96 samples).
>> I only get (begin/commit) input when the buffer size matches or
>> exceeds the buffer length I send out to the card (the set buffer
>> size), and if it exceeds that, I only pick up (commit) one buffer's
>> length of frames. Is this wrong? If there is more input waiting,
>> does ALSA immediately go and POLLIN again, or should I expect it to
>> not bug me again until I've processed a POLLOUT event (the in and out
>> are linked)? I'm not really sure how to handle this..
Basically a bug fixing release but with a number of new opcodes etc
http://souceforge.net/projects/csound
==John ffitch
Notes for 5.13
==============
New Opcodes:
farey sequence opcodes
median opcode
filevalid opcode
Real random number generators using /dev/random (Linux only)
pvstanal opcode -- phase vocoder analysis by reading function tables
mincer opcode -- Phase-locked vocoder processing
temposcal opcode -- Phase-locked vocoder processing with onset
detection/processing
pvswarp opcode -- Warp the spectral envelope of a PVS signal
pvslock opcode -- Frequency lock an input fsig
New Gen and Macros:
INF macro added to orchestras; z read as infinity in scores
GEN for support of farey sequences
Modified Opcodes and Gens:
init changed to allow multiple inits in on statement
maxalloc, cpuperc, instcount now accept named instruments
If normalisation in pow opcodes is zero treat as 1
inch can take upto 20 inputs and outputs
pvscale and pvsmix now have very good spectral envelope preservation
modes (1 = filtered cepstrum, 2 = true envelope).
oscil1 could be static if the duration was long; now there is a
positive minimum increment.
GEN49 now uses search paths
pvsvoc enhanced with new spectral envelope preservation code.
Bugs fixed:
Count of lines fixed in orchestras, and \ inside strings
Fast tab opcodes made safe from crashes
% in formated printing could crash
Double free in fgen fixed
sndwarp quietened (gave too many messages)
gen41 deals with positive probabilities
adsynt reworked removing many bugs
adsynt2 phase error fixed
atonex/tonex did wrong operation
Bug in max number of gens fixed
mp3in could repeat sound at end of file
Better checking in grain4
modulus was wrong in new parser
Better checking in adsyn
changed opcode initialised to zero
Serious bug in tabmorphia fixed
GEN49 has serious bug removed, so no longer incorrect silences.
Partikkel opcode: fixed bug in sub-sample grain placement when
using grain rate FM
nchnls_i working correctly
System Changes:
In the new parser only there are operator @ and @@ to round up the
next integer to a power of 2 or powerof2+1
Score sorting made much faster
lineto improved
Named gens allowed
Various printing include instrument name if available
Command option to omit loading a library
Number of out channels no longer constrained to be number of in
Many fixes to new parser
More use of Warnings than Messages (allows for them to be switched
off)
API:
csoundSetMessageCallback reset if callback set to null
Internal:
usual collection of gratuitous minor changes, layout and comments
Hey, I've been having a lot of trouble with ALSA and processing input
in a full duplex loop, and I was wondering if anyone here had any
insight. I'm using the ALSA poll file descriptor method with the mmap
routines. Typically, my processing loop is blowing past the poll
statement with input requests (POLLIN), causing the CPU usage to go
off the charts as it's basically looping as fast as it can go.
Now, I'm handling the inputs in a way that might not be correct.
Often, ALSA is saying that the available frames is 1.5 times my buffer
size (e.g., I set a 64 sample buffer and ALSA offers me 96 samples).
I only get (begin/commit) input when the buffer size matches or
exceeds the buffer length I send out to the card (the set buffer
size), and if it exceeds that, I only pick up (commit) one buffer's
length of frames. Is this wrong? If there is more input waiting,
does ALSA immediately go and POLLIN again, or should I expect it to
not bug me again until I've processed a POLLOUT event (the in and out
are linked)? I'm not really sure how to handle this..
Cheers,
Louis
Greetings,
I've kept the Audio Plugins page alive at linux-sound.org. It aims to be
a complete list of Linux audio/MIDI plugins, and I've updated it again
recently. Please advise if there are any bad links or other errors.
Also, please advise if there are other plugins that should be on the
list. I *think* I know where to find them all, but you never know who
has an unknown project going on somewhere.
http://linux-sound.org/plugins.html
Best,
dp
hi everybody!
forgive the ot post, but i hope there are some brains to pick here.
i'm planning a studio, and to make it future-proof, there is coax in
every room. currently it's going to be used for rgbhv and composite
video, but i want it to be future-proof for MADI and HD-SDI.
the cabling itself is of sufficient quality, but i'm doubtful about the
connectors. the whole installation has a star topology, so the worst case is
* source
* 5m or so of suitable cable
* bnc wall socket
* 20m installation cable (-63dB/100m @ 3ghz)
* a ghielmetti patchbay (which includes two canare contacts to the patch
cord and two bnc on the rear, unfortunately)
* another 20m installation cable
* bnc wall socket
* another 5m cable
* sink
question 1: any hopes for reliable hd-sdi?
question 2: how can it be that a kick-ass company like ghielmetti does
not offer video patchbays that allow direct connection of coax
installation cables, but require rear bnc connections instead?
question 2b: is there an alternative for direct rear coax connection,
thereby cutting out two potentially disruptive contact surfaces?
question 3: i'm thinking of getting neutrik isolated bnc connectors (the
d-type ones that are semi-recessed and thus well protected from clumsy
passers-by). but their soldering lugs break the coaxial structure -
cause for concern?
question 4: do i really want to solder hf stuff (even though the
voltages are not too high), or will it unsolder itself eventually? any
recommendations as to procedures and tin?
thanks in advance,
jörn
Excerpts from Philipp's message of 2010-03-06 18:30:58 +0100:
> I noticed a while ago that the tapiir website is gone or at least
> non-functional. Do you guys know more about it?
>
> http://www.iua.upf.es/~mdeboer/tapiir/ links to:
> http://www.iua.upf.es/~mdeboer/projects/tapiir/ links to:
> http://www.resorama.com/maarten/projects/tapiir which returns 404
>
> I do have a tarball however, version 0.7.2 and still compiling with
> recent gcc versions:
> http://aur.archlinux.org/packages/tapiir/tapiir/tapiir-0.7.2.tar.gz
>
> If there is a new website or a newer tarball, please let me know.
>
> Regards,
> Philipp
Hi,
it seems the source is still not up or gone again.
Any advice?
I still have db3059abc56a59e9beaed4a8ea693e6b tapiir-0.7.2.tar.gz and
could host it somewhere if that helps anything..
Regards,
Philipp
