Hey all,
I'm learning Vala at the moment, primarily with the intention to develop
apps
which support JACK audio output. I'm gonna work towards GStreamer based
audio routing, and JACK Transport to Start/Stop my app.
For the while, I hope to have a play around with JACK using Vala. So I went
looking for bindings and found the following:
http://www.mail-archive.com/vala-list@gnome.org/msg02266.html
I've read the replies, installed Jack.vapi into /usr/share/vala/vapi
but I cant seem to get rid of some certain errors whenever I compile.
Are others using this binding successfully?
Any tips / info I should know about when using Jack & Vala?
Cheers, -Harry
Hi,
I keep getting surprised at some of the most basic problems I run
into... This time, processing order.
1) Notes of zero duration?
Are these legal MIDI? Do I send a note-on with simultaneous note-off?
Or should they simply be ignored?
2) note x ending simultaneously with note y beginning
For example, a sequence of eighth notes, each an eighth in duration.
As far as processing of these events goes, which should be processed first?
Cheers,
James.
Robin Gareus:
> >
> > 0.49 has this feature implemented. Use the "-jt" option.
> >
> > It should be sample sync,
>
> Almost. It does not yet compensate for port-latency. It is important for
> both effects that introduce latency as well as to keep physical I/O in
> sync with apps.
>
> see jack_port_get_latency() and jack_port_get_total_latency()
> at http://jackaudio.org/files/docs/html/group__PortFunctions.html
>
Thanks for the info! I also wonder, does jack compansate for
latency when it mixes the outputs from ports (i.e. when several
output ports are connected to a jack_capture port), so that
the sound is in sync?
> > but I'm not sure whether the last
> > block (the one that received a stop message from jack transport)
> > should be recorded? For now it's recorded. If that's wrong,
> > I'll fix it in the next release.
>
> While it's safe to just record it, i don't think it should be.
> http://jackaudio.org/files/docs/html/group__TransportControl.html reads:
>
> jack_transport_stop() [..] takes effect on the _next_ process cycle.
>
> jack_transport_query() [..] If called from the process thread, pos
> corresponds to the first frame of the _current_ cycle and the state
> returned is valid for the entire cycle.
>
> IOW: As soon as the app sees a stopped transport in the process loop it
> is exactly at, or already a bit later than the actual end.
>
Thank you very much. This also confirms what I though was most likely.
On Wed, 23 Jun 2010, Kjetil S. Matheussen wrote:
>
> Andrew C:
>>
>> Wow, thanks for the replies guys!
>>
>> Of the software mentioned here, my biggest wish is for syncability with
>> JACK
>> transport, so I can send the output of one of the linuxsampler instruments
>> to the recording software, hit the play button from inside Rosegarden and
>> have a perfectly synced audio copy of one particular instrument output
>> which
>> I can then drop back into the sequencer timeline and continue with another
>> section of the song, thereby freeing up system resources.
>>
>> Of course, this rules out jack_capture I'm afraid!
>>
>
> Sorry, I got this feature request about 4 years ago, but haven't
> implemented it. It should only be about 10-20 extra lines of
> code. I'll do it very soon.
>
0.49 has this feature implemented. Use the "-jt" option.
It should be sample sync, but I'm not sure whether the last
block (the one that received a stop message from jack transport)
should be recorded? For now it's recorded. If that's wrong,
I'll fix it in the next release.
Hello all,
those of you who attended LAC2009 will recognise the Sala
Bianca and lovely metal girl Giorgia:
<http://www.youtube.com/user/WinterHaze01>
Enjoy !
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
And is there a snowballs chance in hell that this is un-encumbered?
<http://electronicdesign.com/tabid/57/default.aspx?topic=algorithm_delivers_…>
Yeah, I sub to a lot of stuff, and occasionally a gem comes by.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Old programmers never die, they just hit account block limit.
> I think that situation is simpler, and is just as you surmise -- you
> can't redistribute a plugin that claims to be under the GPL if it uses
> the VST SDK headers.
>
> There _are_ some VST plugins out there that use the SDK but claim to
> be under the GPL, and I think that is really borne of frustration with
> the current impossibility of "doing it properly" because of the
> restrictive license for the SDK headers (most painfully, the SDK
> license's reverse-engineering clause effectively forbids publishing
> source for a plugin that _doesn't_ use the SDK, if you have already
> accepted the SDK license).
The PC itself famously became an open platform after Compaq clean-room
reverse engineered the BIOS. This is considered legal - Someone who has NOT
agreed to the VST SDK license can re-create headers that mirror the function
of the VST SDK. They must do this by examining/debugging a running VST Host,
not by looking at copy of the original SDK.
You can't include the official VST SDK in a GLP plugin or host.
Jeff McClintock.
A simple question: can GPL plugins be loaded into non-free hosts?
This may appear a stupid question, but given the fact that non-free
code can't link to GPL binaries, what is the story with dynamic modules?
Thanks
Victor
Is there any problem with the list(s) server(s)? The last message that I
received is from friday, but I see in the archive web page that there
was more since that day.
The same seems to happens in LAU.
Natanael.
Hi,
When I'm programming, I find it immensely helpful to be able to plot audio
data at different points in its processing, for debugging, and to test new
ideas.
Essentially I want an oscilloscope, which plots each chunk of 1024 samples.
I've tried using libplot, but it seems too slow. It's causing constant
xruns, even when I only plot every 5th sample.
I thought that maybe libplot was too abstract, and that I needed to draw the
pixels on the screen directly. I tried using SDL, but it caused excessive
xruns also. Simply setting 48000 pixels per second was enough to cause the
flow of xruns. This is *not* erasing the screen, just drawing the points.
I'd expect that erasing the screen is the slow part, but apparently not.
At this point I'm not sure if it's even possible to plot the audio data in
realtime. I did a rough calculation, that on my 2 Ghz cpu, it should have
roughly 40,000 cycles to process each sample. It seems to me that
considering running the whole plugin only uses 1/4 of my cpu, the other
30000 cycles should be plenty to put a pixel on the screen.
So I would guess that something else is the bottleneck, like my video chip,
or maybe the libraries I'm using.
So basically my question is: Has anyone else had any luck with plotting
audio data in real time, and if so, how? Is it not possible to plot every
sample, but only a certain percentage of them? Is there a fundamental
restriction on doing so, or is my problem in software?
Jeremy