TYOQA is officially over.
Qtractor 0.5.3 (delta whisky) drops from angels share!
nuff said :)
Impromptu release highlights:
* Clip drag-and-move stepping with keyboard arrow-keys (FIX)
* Plugin parameter automation GUI feedback (FIX)
* LV2 plugin Qt4 GUI support (FIX)
* Clip/Split on current play-head location (FIX)
Slaintheva!
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
Downloads:
- source tarball:
http://downloads.sourceforge.net/qtractor/qtractor-0.5.3.tar.gz
- source package (openSUSE 12.1):
http://downloads.sourceforge.net/qtractor/qtractor-0.5.3-2.rncbc.suse121.sr…
- binary packages (openSUSE 12.1):
http://downloads.sourceforge.net/qtractor/qtractor-0.5.3-2.rncbc.suse121.i5…http://downloads.sourceforge.net/qtractor/qtractor-0.5.3-2.rncbc.suse121.x8…
- once upon the time, eons ago: user manual:
http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf
Weblog (upstream support):
http://www.rncbc.org
License:
Qtractor is free, open-source software, distributed under the terms
of the GNU General Public License (GPL) version 2 or later.
Change-log:
- Fixed initial LV2 plugin UI widget/window titles.
- Attempt to get any brand new LV2 plugins Qt4 enabled UI's working on
either slv2 and lilv build modes ;) (nailed by falkTX, thanks).
- Current clip is ultimately inferred from the one under the play-head
position and current selected track; the last one clicked over and/or
selected still has precedence (following request by Loiugi Verona).
- Drag-moving clips horizontally with the keyboard arrow-keys just got a
step better with a fixed minimum of one pixel, depending still on the
current snap-per-beat setting and horizontal zoom level (as suggested by
Louigi Verona, thanks).
- Get maximum and minimum peak values back when drawing audio
waveforms.- Automation play/feedback has been missed to show on those
plugins that provide their own GUI, now on par with all the rest
'homebrew' widgets (eg. generic plugin properties dialog).
- All plugin parameters automation and selection were left inaccessible
until the generic native plugin dialog is eventually shown, now fixed
(re. bug #3463916).
Enjoy && Happy New Year!
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Hi folks, wondering if anyone might be able to point me at the way to sort
this out, my latest queue is segfaulting when written to or read from,
while the rest ( which are supposed to be identical except for message type
) are working great, and have been tested with full stack runs fine. I'm
banging my head on the desk at this point trying to find the difference,
but perhaps others have seen similar behaviour?
I've made a template class for a queue, that internally uses a jack
ringbuffer. I have four of them, some of my data message struct, one for a
csound note message struct, and a new one for my raw midi message struct
which looks this this:
struct MidiMessage {
char status;
char data_1;
char data_2;
int time; // time in samples when midi message arrived
};
I instantiate them before anything else and pass them into the components
that need them in their constructors
MessageQueue<DataMessage> *toEngineDataQueue = new
MessageQueue<DataMessage>();
MessageQueue<DataMessage> *fromEngineDataQueue = new
MessageQueue<DataMessage>();
MessageQueue<NoteMessage> *toEngineNoteQueue = new
MessageQueue<NoteMessage>();
MessageQueue<MidiMessage> *fromEngineMidiQueue = new
MessageQueue<MidiMessage>();
All instantiation is working fine, app starts up, and the first three
queues are working. As soon as I either write to or read from the midi
queue, I segfault. Not sure how to debug this, hints welcome! Below is the
cue code in case anyone wants to look at it. I can't see anything wrong,
but maybe I've been doing something wrong and just gotten lucky so far??
thanks
Iain
template <class Type>
class MessageQueue {
private:
// pointer to the ring buffer the ring buffer
jack_ringbuffer_t *mRingBuffer;
int mQueueLength;
public:
MessageQueue();
~MessageQueue();
// put a msg on the queue, returns 0 or error code
void push( Type msg );
// store message in msg, returns true if message
bool tryPop( Type *msg );
};
template <class Type>
MessageQueue<Type>::MessageQueue(){
mQueueLength = DEFAULT_QUEUE_LENGTH;
// create our ringbuffer, sized by Type
mRingBuffer = jack_ringbuffer_create( mQueueLength * sizeof(Type) );
// lock the buffer into memory, this is *NOT* realtime safe
int errorLocking = jack_ringbuffer_mlock(mRingBuffer);
if( errorLocking ){
std::cout << "MessageQueue - Error locking memory when creating
ringbuffer\n";
// XXX raise an exception or something?? how do we fail here??
}
}
template <class Type>
MessageQueue<Type>::~MessageQueue(){
cout << "MessageQueue destructor\n";
// free the memory allocated for the ring buffer
ack_ringbuffer_free( mRingBuffer );
}
template <class Type>
void MessageQueue<Type>::push( Type msg ){
// write to the ring buffer, converting Type to a string
unsigned int written = jack_ringbuffer_write( mRingBuffer, (const char
*) &msg , sizeof(Type) );
// XXX: what to do if it fails anyway??
if( written < sizeof(Type) ){
cout << "Error, unable to write full message to ring buffer\n";
// do something else here yo!
}
}
// if a message is on the queue, get it
// returns True if it got a message
template <class Type>
bool MessageQueue<Type>::tryPop( Type *msgBuf ){
// if there is a message on the ring buffer, copy contents into msg
if( jack_ringbuffer_read_space( mRingBuffer) >= sizeof(Type) ){
jack_ringbuffer_read( mRingBuffer, (char *)msgBuf, sizeof(Type) );
// return True because a msg was read
return 1;
}else{
// return False, no msg read
return 0;
}
}
Hey folks, what is the easiest way to deal with midi input in a jack app?
I'm confused by the difference in jack midi and alsa midi, because I have
two midi inputs, one is a usb input, so it appears at a low level as an
alsa device, but the other is the midi input on a firewire unit, and it
appears as a jack midi device. I'd like to make sure that whatever I do is
easy to port to other systems. Does it make sense to use portmidi or rtmidi
to get input or should I stick to the jack api entirely?
thanks
Iain
Hey all,
I've been writing a scope the last while, and I'm intrested in how other
people have approached plotting the data.
Currently I'm taking every 50th sample, and drawing a line from the
previous sample to there, and so on. Not particulary neat.
So is there a resample, or smoothing of the samples, or how does one plot a
"smooth" waveform like Ardour / QTractor?
My other question is about RMS, is calculating it in its literal sense
best? Or perhaps only taking every 5th sample?
Resampling the signal from 44.1 or 48k to say 11025? I'm not really sure
which way to go.
Cheers, -Harry
Hi there,
I could use some advise.
You may or may not heard of replaygain. It's reasonably widely used in
consumer audio, but sometimes I wish it was available for video as well.
By this I mean I wish it was available for the audio part of the video.
Well, I need a programming project for a university course and this is
just one of my ideas that I want to propose to my teacher and
prospective teammates. In order to do this I'd like to narrow it down a
bit further and especially want to find out whether I have the right
idea of how it can be achieved.
Scanning/tagging
Since replaygain works on whole audio files I think I need to extract
the whole audio track from the container. How easily this can be
achieved I don't know. After that, the scanning process should work as
with any audio file. Afterwards the calculated replaygain values have to
be added to the metadata of the file. I have no idea how hard it is to
add new metadata fields to video formats.
Playback
Video players need to be aware of those tags, read the metadata and scale
the playback volume accordingly. This is probably not hard per se, but
there are many players out there. However, I plan to start with a single
player, even with a single file format, and go from there.
Question 1: Is there anything better than replaygain that should be used
instead?
Question 2: Which player would be easiest to hack to add such
functionality? Could it be a gstreamer plugin? mplayer?
Question 3: How much work would it be?
The project should be done in C++ if possible, otherwise C. Group size
2-4 Students, all rather new at C/C++ and rather inexperienced in
general.
Other ideas I have are in short:
- A CLI (using readline) connection manager for jack audio/midi and alsa
midi that can handle large numbers of ports. More detailed ideas exist
thanks to Julien Claasen.
- A simple but hopefully sane mplayer GUI
- A new GUI for ecasound
Another problem I might have is that most students in the course are
Windows users, not sure whether I can go solo.
Thanks for any advice,
regards,
Philipp
Hi everyone. I'm starting to write a simple filter and I want to expose it
as an lv2 plugin.
My development environment is very simple right now: vim editor, gcc
compiler, package the lv2 manually (will write a script for that in a day
or two) and then load the plugin in ardour to test it.
I've found this setup to be a bit unconfortable because once I load the
plugin in ardour I don't know how to get debug information from it (print
statements or breakpoints with gdb).
What does a lv2 development environment typically looks like? what are you
guys using?
Thanks!
--
Rafael Vega
email.rafa(a)gmail.com
Apologies for cross-posting.
======================
We are pleased to announce the release of version 5.15. The sources
are on the standard Sourceforge location
(https://sourceforge.net/projects/csound/files/csound5/csound5.15/)
as both zip and tar.gz
Platform packages will follow shortly, and the manual on Friday.
==John ffitch
------------------------------------------------------------------------
Notes for 5.15
==============
New parser has been subjected to a great deal of work. It now has
better checking of argument types and use, better diagnostics and
increased functionality. We have only reached this stage in the last
few days so we judge it prudent to leave the old parser as standard.
We would be pleased if more users tried the new and gave the
developers feedback.
A major reorganisation means that there are many fewer plugins and
most opcodes are in the base (about 1250 of them). A side effect of
that is that leaving old plugins from an earlier release is a
disaster, and so 5.15 will not load earlier plugins.
The multicore system is now safe (ie maintains semantics) when zak,
channels or table modification are made.
New Opcodes:
ftab2tab transfers between ftables and t-variables
tab2pvs tsig - pvs conversion
pvs2tab pvs - tsig conversion
cpumeter-- not really new but now available in OSX
(EXPERIMENTAL) ftresize and ftresizei allow resizing of
existing tables. These will be permanent if the
community feel they are useful.
minmax opcodes
hrtfearly, hrtfreverb opcodes
New Gen and Macros:
Code to allow GEN49 to be deferred [NB does not seem to work]
Modified Opcodes and Gens:
socksend and sockrecv no longer uses MTFU check and work on Windows
mpulse changed so if next event is at negative time use the absolute value
serial opcode now runs on Windows as will as Un*x
out, out2, outq, outh, outo outx and out32 are now identical
opcodes and will take up to as many arguments as nchnls.
This replaces the current remapping of opcodes
turnoff2 now polymorphic wrt S and k types (ie accepts instrumnet names)
Utilities
Bugs fixed:
GEN42 fixed
jacko: fixed a segfault removing the unused JackSessionID option
doppler memory leak fixed
transegr fixed in release mode when skipping most of envelope
FLPack now agrees with manual
max_k now agrees with manual
hrtfreverb fixed
atsa code now works on Windows in more cases
tabmorph bug fixed
fixed problem with user-defined opcodes having no outputs
Various fixes to * ... */ comments
System Changes:
Various licence issues sorted
Loris is no longer part of the Csound tree
Memory leaks fixed
If no score is given a dummy that runs for over 100 years is
created
All score processing takes place in memory without temporary
files
String memory now expandable and no size limitation
#if #else #end now in new parser
Adjustments to MIDI file precision in output
On OSX move from Coreaudio to AuHAL
Multicore now safe for ZAK, Channels and modifying tables
New coremidi module
Virtual Keyboard improved:
1) Dropdown for choosing base octave (the one that
starts with the virtual key mapped to physical key
Z). Default value is 5 which is backwards compatible.
2) Shift-X mappings which add two octaves to X
mappings for a total of 4 octaves playable from the
physical keyboard (starting from selected base octave).
3) Control-N / Control-Shift-N mappings to increment
/ decrement slider for control N.
4) Mouse wheel now controls sliders.
tsig type for vectors
tsigs and fsigs allowed as arguments in UDOs
API:
Minor version upped
Internal:
Very, very, very many!
Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie
Hi, I'm sure others have tackled this and have some wisdom to share. My
project is principally a monosynth step sequencer. This is nice an simple
to do in real time because resolution is very limited and there can be only
one note per track. So step sequenced note data is stored in simple
multi-dimensional arrays, making reading and writing very easy, and
messaging simple between audio and gui threads.
However, I would like to add the ability for the user to send a message and
have it get executed later, where later gets figured out by the engine ( ie
on the top of the next 8 bar phrase ). To do this, I need some way of
storing deferred events and having the engine check on each step whether
there were any deferred events stored for 'now'. I can think of a few ways
to do this, and all of them raise red flags for a real time thread.
- I could use a hash table, hashed by time, with a linked list of all the
events for that time. The engine looks up the current time and gets all the
events. I don't know much about hashing so I'd prob just use Boost, is that
a bad idea?
- I could make a linked list of all deferred events and iterate through
them checking if time is now. There wouldn't be any hashing, but maybe this
list would be really big.
Anyone have any suggestions for how to safely do the above or some better
alternative?
thanks!
iain
On , Tristan Matthews <le.businessman(a)gmail.com> wrote:
> You might find some inspiration in sndpeek:
> http://soundlab.cs.princeton.edu/software/sndpeek/
Definatly! Thanks, got linux-alsa compiling, but linux-jack is segfaulting
in RtAudio::startStream()... debuggin atm :)
Cheers, -Harry
