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
howdy
so i lied, bluffed all the way, so what? should I be sorry? what you'd
expect from this one self-called ber-procrastinator ? and then there's
hope. alas, not the messiah, rather my development drive at my own pace.
believe it or not, it is on-going and it will sure happen real soon ;)
no sweat. The whole automation prophecy will be realized and delivered.
yes, TYOQA just failed, slipped a bit. it doesn't mean it was abandoned
though or, uh, procrastinated... well, it's only a happy new year after
all:)
the road to automation is being already being paved and walked although,
i must say, it is no yellow-bricked one. the drive has begun.
definitely, 2011 will be TYOQA (aha, read that again with a bold tee:)!
more than automation, which infrastructure is already lurking in there,
trus me, all work is being carried out at the backyard for the time being.
blossoms might just pop out this spring ;)
one thing i may wish to leave sound and clear: it is very likely that,
in the very near future, that there will be some dot-release before the
all-mighty-one release, whatever. now that the surprise-effect is gone,
the long overdue and hailed beta release cycle that will present you and
carve its deeds on stone with the dynamic-curves and automation features
et al., will be nothing less nor before the coming version numbered as
the 0.5.x scheme. then, and only then, the current alpha-cycle will be
concluded. of course, that will be also the time for translations to be
called in. just be a little more patient :)
and then i lied a second time, when said those parodied f&d release
code-names were exhausted. thanks to a lengthy but intermittent
fall/winter-of-coding period, i had the chance to wake up one morning
with the imagination score in its lowest end and roar an inner WTH! as
they say around here, there's no second without a third. so another lie
is there waiting to be told. or is it not? there, one would say: time
will tell...
Release highlights:
* Archive/Zip session file bundle (save as... .qtz) (NEW)
* Mixer MIDI controller mapping/learn (NEW)
* LV2 GTK UI support (NEW)
* LV2 Persist extension support (NEW)
* MIDI Tools on main track/clips view(NEW)
* Floating tool-tips while dragging/moving/pasting (NEW)
* Rescale and Timeshift MIDI tools (NEW)
* MIDI Quantize percentage (NEW)
* Track range selection (NEW)
* Audio insert send, wet/dry controls (NEW)
* Audio clip pitch-shifting (FIX)
* Metronome dedicated outputs related crash (FIX)
* Stop transport tool/button action (NEW)
* Mouse-wheel zooming (NEW)
and a few more assorted features and fixes--see below the complete
(boring) change-log for gruesome details.
Nuff said.
Qtractor 0.4.8 (fiery demigoddess) released!
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
Downloads:
- source tarball:
http://downloads.sourceforge.net/qtractor/qtractor-0.4.8.tar.gz
- source package (openSUSE 11.3):
http://downloads.sourceforge.net/qtractor/qtractor-0.4.8-2.rncbc.suse113.sr…
- binary packages (openSUSE 11.3):
http://downloads.sourceforge.net/qtractor/qtractor-0.4.8-2.rncbc.suse113.i5…http://downloads.sourceforge.net/qtractor/qtractor-0.4.8-2.rncbc.suse113.x8…
- user manual (archeologically dated):
http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf
Weblog (upstream support):
http://www.rncbc.org
License:
Qtractor is free, openosource software, distributed under the terms of
the GNU General Public License (GPL) version 2 or later.
Change-log:
- MIDI controller mapping/learn is now possible on all mixer controls
(monitor, gain, panning, record, mute, solo).
- An internal rewrite (aka. refactoring) have been carried out, making
sure that all track state action buttons (R, M, S) are now all under the
observer pattern umbrella.
- Single track range selection is now available on main menu
(Edit/Select/Track Range; default keyboard shortcut: Ctrl+Shift+R);
additionally to vertical range and horizontal track actions
(Edit/Select/Range, Track) all these operations can now toggle over the
previous selection.
- Direct clip selection from Files list item has been brute-forcefully
implemented (after being challenged by Jiri Prochaszka aka Anchakor:).
- Files tree widget sticky "New Group" item fixed.
- A new menu option has been added (View/Tool Tips) to show/hide a
floating tool-tip while dragging, moving, resizing or pasting selected
clips or events over the main tracks view and MIDI clip editor
(piano-roll) respectively, displaying current target position and status.
- Attempt to reset audio/MIDI time drift compensator on every engine
start and loop turnaround.
- Moving the punch-out marker over the main track time ruler was failing
to shrink the punch-in/out range, now it does (not).
- MIDI clip tools (quantize, transpose, normalize, randomize, resize,
rescale and the new timeshift) are now all accessible from the main
tracks view (Edit/Clip/Tools menu) and apply to all events on current
selected clip(s).
- LV2 Persist extension support is being introduced.
- A new timeshift MIDI tool has been added, after an awesome patch by
Jiri Prochaszka aka Anchakor; applies to selected events between edit
markers, distorting their time and duration (optionally), either slowing
down and accelerating, based on a given parameter P value.
- Audio clip/buffer pitch-shifting fixes with regard to latency
correction due on the RubberBand library one-pass (real-time) processing
mode.
- New Send Gain and Dry/Wet control parameters have been implemented for
audio Inserts pseudo-plugins.
- MIDI channel/master volume enqueued events are now affected by the
current track/bus volume (0-100%).
- Prevent old rounding error when resetting to plugin parameter default
value with the mouse middle-button click while hovering a slider widget
(observer).
- A quantize percentage has been added to MIDI clip editor quantize tool
(Tool/Quantize...) for time and duration quantization (0% for none; 100%
for full regular quantization).
- Metronome bus/ports are now created at engine start and not when user
switches it on anymore.
- Make sure all audio clip buffers are in sync upon smooth-ramping going
off and playback is rolling.
- Copy-pasting across controller event types is now possible on the MIDI
clip editor (aka piano-roll).
- Finally indulged, the genuine transport stop button makes its
appearance on main toolbar and menu.
- Main tracks grid visibility option (View/Snap/Grid).
- Yet another off-by-one (frame) audio buffer bug got squashed away:
rare symptom was that some audio clips were being left dead silent right
after playback of their first looping period.
- Plugin parameter name/label now a proper attribute of its respective
MIDI Controller observer instance, allowing to be shown on dialog title
(MIDI learn).
- Default session file format saved on JACK session demand is now the
bundle archive/zip one (.qtz).
- Plugin selection dialog now shows whether a plugin features its own
editor (GUI) and/or external state configuration (EXT).
- Help/Shortcuts... window positioning and sizing are now preserved.
- All plugin chain changes over the track properties dialog now sure
counts as a dirty action (possibly fixing bug #3104129).
- Newly extracted archive/zip session directories are now removed
automatically from the file-system on session close, prompting the user
for confirmation (cf. View/Options.../Display/Confirm Removals).
- Ctrl+mouse-wheel is now set for zooming in/out, on main track-view and
all applicable MIDI clip editor views (piano-roll), according to current
zoom mode (see View/Zoom Horizontal, Vertical or All for both ways
simultaneously).
- New MIDI clip editor (piano-roll) mouse hovering effect (eye-candy++).
- After too many a user request, a brand new session archive file type
is being introduced (.qtz) which tries to bundle in one single zip
archive all the media and contents of a session.
- Add that to eye-candy: either loop or punch-in/out outer ranges are
now shaded on the main track-view, thumb-view and MIDI clip editor
(piano-roll) views.
- LV2 GTK UI plug-in hosting is now roaring its ugly head (EXPERIMENTAL).
- Ignore all initial and decremental notifications of audio engine's
buffer-size changes.
- Internal audio buffer loop points were not being set properly for
non-zero clip offsets, leaving some as severely out-of-sync while
rolling over loop turns. Now fixed again, hopefully.
- Avoid audio peak file clashing when deriving from audio sample files
with distinct absolute paths but the very same file (base)name.
- A new MIDI editor (piano-roll) tool has been added: Rescale event
times, durations and/or values by a percentage between 1 and 1000%
(adapted thanks to patch #3081954, by Jesse Lucas).
- Attempt to mitigate audio clip sequencing glitches on
single-core/single-thread machines.
cheers && enjoy (be happy!)
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
