Re: [LAD] aBLETON lINK
On Thu, Sep 22, 2016 at 04:36:17PM -0500, Paul Davis wrote: > On Thu, Sep 22, 2016 at 4:27 PM, Tito Latini <tito.01b...@gmail.com> wrote: > > > On Thu, Sep 22, 2016 at 12:49:42PM -0500, Paul Davis wrote: > > > The innovation is defining an API and protocol based on 3 concepts: > > > > > > tempo synchronization > > > > an integral to get the position with the new bpm > > > > across a network? with multiple tempo masters? I respectfully think you don't understand the technical problem. We send/receive informations about the time, the change of the tempo and/or the position of a beat, the updated number of the participants, the time window to get the next temporal change, a message "too soon" to discard or defer a change, the minimal time window, latency, etc, but not the performance of the change. That's a protocol. The integral is software-side, not across the network. It's not always necessary because it depends on the musical instrument. For example, a string quartet uses a particular curve to change the tempo; the curve is possibly different with pizzicato; a drum machine plays in ritardo or fills the time window with a roll. The modus operandi is arbitrary for an application, the network is used to share the information about the clock and the possible changes (start-time, end-time, from-bpm, to-bpm, from-position, to-beat, etc). Under the hood, the synchronization of the beat is the change of a local bpm. For example, tempo-change + beat alignment is a combination of two integrals (software-side) if the instrument plays accelerando or ritardando. The coder of the program/library is responsible of the curve-palette and the optimization. One common protocol to communicate, many programs/libraries to play. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] aBLETON lINK
On Thu, Sep 22, 2016 at 07:58:03PM +0200, Robin Gareus wrote: > [...] > Also coming up with a protocol is the easier part. Documenting it, > pushing it out to users, gaining traction in the industry etc is the > hard part. opus-codec is an example of authentic Art (rfc, code, etc) and not genuflextion. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] aBLETON lINK
On Thu, Sep 22, 2016 at 12:49:42PM -0500, Paul Davis wrote: > The innovation is defining an API and protocol based on 3 concepts: > > tempo synchronization an integral to get the position with the new bpm > beat alignment ask to live coders > phase alignment related to beat alignment > Whatever you've done in incudine, it doesn't define an actual tempo map > that can and will be shared among applications, which was always the > sticking point for JACK to be able to do this. It isn't hard to define such You always think in JACK. I'm talking about an independent, public and possibly standard protocol; if you know the recipe, you write what you want. The implementation in JACK, a library from Ableton, etc, is a welcome side effect. I want the freedom to sync a little device in assembly. One time, without the necessity to check the updates of the "protocol" on the AL web page. You (not only Paul) are being much too defensive; perhaps I'm writing on the wrong list. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] aBLETON lINK
On Thu, Sep 22, 2016 at 09:16:12AM -0500, Paul Davis wrote: [...] > Ableton have now done that, albeit by circumventing the hardest parts of > the problem (a tempo map with varying meter and tempo). What? I repeat: that's not an innovation. >From Incudine web page [1]: Features [...] * Tempo change with arbitrary curves [...] Public and visible to *all* from commit 2fbf62068e50ef65e15a235454540ac4a22500ab Author: Tito Latini <tito.01b...@gmail.com> Date: Fri Oct 25 11:21:55 2013 +0200 complete temporal envelope - new structure TEMPO-ENVELOPE - new utilities: SET-TEMPO-ENVELOPE, TIME-AT, BPS-AT and BPM-AT - the syntax for the #[... b.* ...] read-macro becomes: #[NUM-OF-BEATS b.*] ; *TEMPO* by default #[NUM-OF-BEATS b.* TEMPO] #[NUM-OF-BEATS b.* TEMPO-ENVELOPE OFFSET-IN-BEATS] The source is in incudine/src/time.lisp [2] (GPL v2) If you read lisp, here is a part of the tutorial about tempo mapping (the original is online [3] or with the source code incudine/doc/html/tutorial_02.html or the text file incudine/doc/tutorials/getting_start_2.cudo): --[START TUTORIAL CUT]-- The structure TEMPO-ENVELOPE is specific for a temporal envelope. The constructor is MAKE-TEMPO-ENVELOPE, and SET-TEMPO-ENVELOPE is useful to change an existent instance. ;;; The utilities to get the time, the bps and the bpm are: (time-at tempo-env beats offset) (bps-at tempo-env beats) (bpm-at tempo-env beats) ;;; The syntax for the #[... b.* ...] read-macro is: #[NUM-OF-BEATS b.*] ; *TEMPO* by default #[NUM-OF-BEATS b.* TEMPO] #[NUM-OF-BEATS b.* TEMPO-ENVELOPE OFFSET-IN-BEATS] ;;; Example: ;;; After 8 beats, there is an acceleration from 60 to 120 bpm in 4 beats, ;;; with coeff 4 for the curvature. Then, after 2 beats, there is a ;;; deceleration from 120 to 96 bpm in 2 beats, with sinusoidal curvature. SCRATCH> (defvar *tenv1* (make-tempo-envelope '(60 60 120 120 96) '(8 4 2 2) :curve '(:step 4 :step :sin))) *TENV1* SCRATCH> (loop for beats below 20 by 0.5 collect (time-at *tenv1* beats)) (0.0d0 0.5d0 1.0d0 1.5d0 2.0d0 2.5d0 3.0d0 3.5d0 4.0d0 4.5d0 5.0d0 5.5d0 6.0d0 6.5d0 7.0d0 7.5d0 8.0d0 8.498612626829395d0 8.993299378541845d0 9.481513456442876d0 9.959055899352716d0 10.419003790659431d0 10.849943170489647d0 11.233055600417206d0 11.537314720727547d0 11.787314720727547d0 12.037314720727547d0 12.287314720727547d0 12.537314720727547d0 12.790429835847638d0 13.060025984954574d0 13.352929835847638d0 13.662314720727547d0 13.974814720727547d0 14.287314720727547d0 14.599814720727547d0 14.912314720727547d0 15.224814720727547d0 15.537314720727547d0 15.849814720727547d0) SCRATCH> (loop for beats below 20 by 0.5 collect (bps-at *tenv1* beats)) (1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 0.9939482867384511d0 0.9839706983599575d0 0.9675204361700447d0 0.9403985389889412d0 0.8956820902047142d0 0.8219571299439862d0 0.7004052197806022d0 0.5d0 0.5d0 0.5d0 0.5d0 0.5d0 0.5183058261758408d0 0.5625d0 0.6066941738241592d0 0.625d0 0.625d0 0.625d0 0.625d0 0.625d0 0.625d0 0.625d0 0.625d0) SCRATCH> (loop for beats below 20 by 0.5 collect (bpm-at *tenv1* beats)) (60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.36531356866102d0 60.97742554733141d0 62.01419397145924d0 63.80273629998226d0 66.98805374827423d0 72.99650774254955d0 85.6646956725917d0 120.0d0 120.0d0 120.0d0 120.0d0 120.0d0 115.76177030980232d0 106.67d0 98.8966147833654d0 96.0d0 96.0d0 96.0d0 96.0d0 96.0d0 96.0d0 96.0d0 96.0d0) SCRATCH> *sample-rate* 48000.0d0 SCRATCH> (loop for beats below 20 by 0.5 collect #[1 beat *tenv1* beats]) (48000.0d0 48000.0d0 48000.0d0 48000.0d0 48000.0d0 48000.0d0 48000.0d0 48000.0d0 48000.0d0 48000.0d0 48000.0d0 48000.0d0 48000.0d0 48000.0d0 48000.0d0 47933.40608781097d0 47678.37017000858d0 47179.23982144708d0 46356.31299892179d0 44999.536042394655d0 42762.58901457268d0 39074.486868373184d0 32993.834411419215d0 26604.43777489638d0 24000.0d0 24000.0d0 24000.0d0 24149.525525764348d0 25090.140682897298d0 27000.0d0 28909.859317102702d0 29850.474474235652d0 3.0d0 3.0d0 3.0d0 3.0d0 3.0d0 3.0d0 3.0d0 3.0d0) --[STOP TUTORIAL CUT]-- [1] http://incudine.sourceforge.net/ [2] https://raw.githubusercontent.com/titola/incudine/master/src/time.lisp [3] http://incudine.sourceforge.net/tutorial_02.html ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] aBLETON lINK
Thanks Patrick. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] aBLETON lINK
On Tue, Sep 20, 2016 at 12:04:53AM +0200, Robin Gareus wrote: > On 09/19/2016 11:56 PM, Patrick Shirkey wrote: > > > >> why? > >> > >> On Sat, Sep 17, 2016 at 5:44 PM, Tito Latini <tito.01b...@gmail.com> > >> wrote: > >> > >>> What is the content of the network packets ? > >>> > >>> Regardless, I'll ignore software with that technologogy. > >> > > > > The OP seems to be suggesting that whoever has access to the data captured > > by Ableton Link or the potential backdoor that link *might* enable would > > use it for nefarious purposes. > > Ableton link is used to synchronize software and devices on a *LAN*. > It basically broadcasts BPM and song-position to the *local* network. > > Link does not allow to synchronize devices on a WAN. > > The complete source code is free (GPLv2) you can read it, no strings > attached. I know how to read the code; done before to send the first message. My question is a provocation for the sleepers. The synchronization with other devices through the network to share bpm, time, positions, strings, etc, is not an innovation. Many persons (me too) use private protocols written ad hoc from scratch to sync the devices within a room. Non standard protocols, useful for limitated circumstances. A standard protocol is better (i.e. NTC, Network Time Code). I can discover the current protocol used by AL (thanks for the additional work) and use my network interface to dialog, for example, with Reason. If AL fixes some problems or decides to change the protocol, Reason is updated but my code fail. It is necessary other work to learn the changes. With a public protocol, there are two or three revisions, then there is the possibility to get a standard. It is simplest and professional. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] aBLETON lINK
What is the content of the network packets ? Regardless, I'll ignore software with that technologogy. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK and vanilla 3.19.2 startup issue
On Sat, Jun 06, 2015 at 03:35:16PM +0100, Harry van Haaren wrote:
On Sat, Apr 4, 2015 at 8:13 PM, Adrian Knoth a...@drcomp.erfurt.thur.de
wrote:
Not enough information. I recommend starting jackd with strace
Done - apologies for the delay. Strace output available[1], but the most
interesting part copied here:
sched_get_priority_min(SCHED_FIFO) = 1
sched_setscheduler(0, SCHED_FIFO, { 1 }) = -1 EPERM (Operation not
permitted)
write(2, \nJACK is running in realtime mod..., 87
JACK is running in realtime mode, but you are not allowed to use realtime
scheduling.
) = 87
This code tries to call sched_setscheduler() with SCHED_FIFO. My bet is
that your almost vanilla kernel fails to fulfil this request, but
strace will tell you for sure.
By almost vanilla I meant the Arch linux packaged version - I didn't
change the config myself (and Arch aims to be true to vanilla). A very
accurace prediction though - indeed sched_setscheduler() is causing a
return of -1. This is running as root though - so something is wrong here.
The question is why said call should fail. The only thing that comes to
my mind are CGROUPS. Maybe your old kernel comes without, the new kernel
supports them and the configuration is set in a way that disables
SCHED_FIFO by default.
Perhaps - I'm not experienced with cgroups or such, if anybody has any test
ideas for me I'll try them out?
No tested but perhaps the follow lines in __sched_setscheduler
(linux-3.19.8/kernel/sched/core.c) are relevant:
#ifdef CONFIG_RT_GROUP_SCHED
/*
* Do not allow realtime tasks into groups that have no runtime
* assigned.
*/
if (rt_bandwidth_enabled() rt_policy(policy)
task_group(p)-rt_bandwidth.rt_runtime == 0
!task_group_is_autogroup(task_group(p))) {
task_rq_unlock(rq, p, flags);
return -EPERM;
}
#endif
#ifdef CONFIG_SMP
if (dl_bandwidth_enabled() dl_policy(policy)) {
cpumask_t *span = rq-rd-span;
/*
* Don't allow tasks with an affinity mask smaller than
* the entire root_domain to become SCHED_DEADLINE. We
* will also fail if there's no bandwidth available.
*/
if (!cpumask_subset(span, p-cpus_allowed) ||
rq-rd-dl_bw.bw == 0) {
task_rq_unlock(rq, p, flags);
return -EPERM;
}
}
#endif
However I'm using 3.10 compiled without CONFIG_RT_GROUP_SCHED and the
second `#ifdef' (CONFIG_SMP) is not present in the source code.
Hypothesis: the second condition fails
= disable the bandwidth management logic (the default is 95):
echo -1 /proc/sys/kernel/sched_rt_runtime_us
More info about sched_rt_runtime_us:
scheduler/sched-rt-group.txt: 2.1 System wide settings
scheduler/sched-deadline.txt: 4.1 System wide settings
If it continues to fail and your kernel is compiled with
CONFIG_RT_GROUP_SCHED, you could recompile it without this
configuration option (if you don't use realtime group scheduling).
Oh, if it continues to fail, see the other branches with `return -EPERM'
in __sched_setscheduler.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ambix vs JUCE, segfault
On Sun, Apr 12, 2015 at 07:29:41PM -0700, Fernando Lopez-Lezcano wrote:
Anyone out there using ambix on Linux?
I'm seeing various instabilities, for example trying out the converter
standalone I get a segfault when connecting output ports, and it looks
like the Jack JUCE component is doing some unaligned memory copies.
Any hint on how to fix this?
I get Ardour crashes if I try to use the converter LV2 plugin as well.
See below for a trace of the standalone binary...
Thanks for any help!
-- Fernando
[...]
I have compiled the git-version and tested with the converter standalone.
The attached patch should fix this problem.
diff --git a/ambix_converter/Source/PluginProcessor.cpp
b/ambix_converter/Source/PluginProcessor.cpp
index de0c471..7170db0 100644
--- a/ambix_converter/Source/PluginProcessor.cpp
+++ b/ambix_converter/Source/PluginProcessor.cpp
@@ -511,27 +511,12 @@ void Ambix_converterAudioProcessor::processBlock
(AudioSampleBuffer buffer, Mid
ACNtoLM(i, l, m);
-int _in_ch_seq = in_ch_seq[i];
-int _out_ch_seq = out_ch_seq[i];
-
-if (in_2d)
-{
-_in_ch_seq = in_2d_ch_seq[ACN3DtoACN2D(i)];
-if (_in_ch_seq getNumInputChannels())
-_in_ch_seq = -1;
-}
-
-if (out_2d)
-{
-_out_ch_seq = out_2d_ch_seq[ACN3DtoACN2D(i)];
-if (_out_ch_seq getNumOutputChannels())
-_out_ch_seq = -1;
-}
-
+int _in_ch_seq = in_2d ? in_2d_ch_seq[ACN3DtoACN2D(i)] : in_ch_seq[i];
+int _out_ch_seq = out_2d ? out_2d_ch_seq[ACN3DtoACN2D(i)] :
out_ch_seq[i];
// std::cout InputCh: i IN_CHANNEL: _in_ch_seq
OUT_CHANNEL: _out_ch_seq std::endl;
-if (_in_ch_seq != -1 _out_ch_seq != -1 _in_ch_seq
getNumInputChannels())
+if (_in_ch_seq getNumInputChannels() _out_ch_seq
getNumOutputChannels())
{
// copy input channels to output channels!
output_buffer.copyFrom(_out_ch_seq, 0, buffer, _in_ch_seq, 0,
NumSamples);
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] jack1 unsafe with accidentally (?) internal exported functions
Hi, some internal functions are globals and I think it is not what you want
(jack2 seems ok).
For example, a naive way to forbid the creation of other jack clients is:
# tested with jack 0.124.1
gcc -ljack private_club_mode.c
./a.out # prints JACK compiled with System V SHM support.
echo $? # 0
jack_lsp # no more clients please, segfault (jack_client_open_aux)
/* private_club_mode.c */
#include jack/jack.h
int jack_register_server(const char *, int);
int main() {
return jack_register_server(umpa, 0xDADA);
}
Tito
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] jack1 unsafe with accidentally (?) internal exported functions
On Mon, Mar 16, 2015 at 01:22:56PM -0500, Paul Davis wrote:
Although their export is a mistake, I really don't see this as of any
particular importance.
JACK is almost always a per-user system. JACK also allows clients to
scribble all over each other ports. The fact that someone can write an
application which does this is really not much of an issue compared to that.
live coding over net is trendy and there are tools linked to libjack,
often with the possibility to call foreign functions. In this context,
an user without particular privileges could cause a crash to the root.
Regardless, to complete the report, the hidden functions are:
cleanup_mlockdefault_jack_error_callback
default_jack_info_callback jack_attach_port_segment
jack_attach_shm jack_call_sync_client
jack_call_timebase_masterjack_cleanup_shm
jack_client_allocjack_client_alloc_internal
jack_client_deliver_request jack_client_fix_port_buffers
jack_client_handle_latency_callback jack_client_handle_port_connection
jack_client_handle_session_callback jack_client_open_aux
jack_clock_source_name jack_default_server_name
jack_destroy_shm jack_event_type_name
jack_generate_unique_id jack_get_all_descriptions
jack_get_description jack_get_free_shm_info
jack_get_mhz jack_get_microseconds_from_cycles
jack_get_microseconds_from_systemjack_get_port_functions
jack_get_process_done_fd jack_hpet_init
jack_init_time jack_initialize_shm
jack_internal_client_load_auxjack_messagebuffer_add
jack_messagebuffer_exit jack_messagebuffer_init
jack_messagebuffer_thread_init jack_midi_internal_event_size
jack_pool_alloc jack_pool_release
jack_port_by_id_int jack_port_by_name_int
jack_port_name_equalsjack_port_new
jack_port_type_buffer_size jack_register_server
jack_release_shm jack_release_shm_info
jack_resize_shm jack_server_dir
jack_set_clock_sourcejack_shmalloc
jack_start_freewheel jack_stop_freewheel
jack_transport_copy_position jack_unregister_server
jack_user_dirsilent_jack_error_callback
start_server
(obtained with the follow imperfect script, useful to discover
exported internal functions also in other non-stripped libraries)
#!/bin/bash
# Discover JACK's hidden functions.
#
# example:
# ./jack_hidden_functions /usr/lib64/libjack.so /usr/include/jack/*
#
find_headers()
{
local fname=$1
shift
sed -n '/[^A-Za-z0-9_]*'${fname}'[^A-Za-z0-9_]/{\_^[ \t]*/\?\*_d;\_^[
\t]*//_d;p}' $@
}
globl_without_header()
{
while read lib; do
[ -z $(find_headers ${lib} $@ | head -1) ] echo ${lib}
done
}
main()
{
if [ ! -f $1 -o ! -f $2 ]; then
echo Usage: $(basename $0) libfile hfile [hfile...]
exit 2
fi
local libpath=$1
shift
nm ${libpath} | awk '$2 == T {print $3}' | globl_without_header $@
}
main $@
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
