Re: [LAD] B.Spacr - New LV2 sound effect plugin

[Will J Godfrey]

This looks very promising indeed.
Any possibility of a Windows port?
 
-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] A short technote on digital state-variable filters

[Will J Godfrey]

On Thu, 19 Nov 2020 22:05:00 +0100
Fons Adriaensen  wrote:

>Hello all,
>
>Some people have asked me to provide a bit more documentation
>on the state-variable filters I used in zita-eq1 and zita-jacktools.
>
>So I've written a short technical note on this. You can find it at
>
>
>
>Ciao,
>

Thanks for this. Very interesting. I recognised the hardware drawing instantly.
I used a variant on an amp some years ago for splitting out sub-bass, just
using the high and low pass outputs. It made tuning to suit the actual speakers
extremely easy.

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] G++ trouble

[Will J Godfrey]

On Mon, 16 Nov 2020 16:31:18 +0100
Fons Adriaensen  wrote:

>or
>
>* Just #define it in a header (e.g. globals.h) instead of creating 
>  a variable.
>
> 
>Ciao,
>

Thanks again. I've gone for this options. It keeps these together, along with a
bunch of enums so they're easy to find.

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] G++ trouble

[Will J Godfrey]

On Mon, 16 Nov 2020 14:52:53 +0100
Alexandre DENIS  wrote:

>On Mon, 16 Nov 2020 13:38:01 +0000
>Will J Godfrey  wrote:
>
>> Not wishing to hijack this thread but I'm still confused :(
>> 
>> I just did a search of the whole of src. It's *used* about a dozen
>> times across 5 otherwise unrelated .cpp files, but is only defined
>> here. Just to be certain, I did a make clean before trying this
>> again, and it's definitely saying multiple defs
>> 
>> e.g
>> /usr/bin/ld:
>> CMakeFiles/yoshimi.dir/UI/WidgetMWSlider.cpp.o:(.rodata+0x0):
>> multiple definition of `ADD_COLOUR';
>> CMakeFiles/yoshimi.dir/Interface/InterChange.cpp.o:(.rodata+0x1840):
>> first defined here
>> 
>> This happens at the linker stage.
>> 
>> Also, I thought the whole idea of putting things like this in a
>> #ifndef/#def block was to ensure it was only set once.
>>   
>
>It is only set once *per file* which includes the header. But since the
>symbol is extern, the linker sees one public copy per file, which
>conflict with each other.
>
>-a.
>
Thanks. Clear now. Some reorganisation needed :(

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] G++ trouble

[Will J Godfrey]

On Mon, 16 Nov 2020 13:35:30 +0100
Fons Adriaensen  wrote:

>On Mon, Nov 16, 2020 at 12:22:54PM +0000, Will J Godfrey wrote:
>
>> In GCC 8.3 doing that in a globally included header actually *creates* a
>> multiple definitions error!
>> 
>> #ifndef GLOBALS_H
>> #define GLOBALS_H
>> 
>> const unsigned int ADD_COLOUR = 0xdfafbf00; fine  
>
>Putting a definition in a header file is usually a bad idea.
>What you get from this (without 'extern' is a separate copy
>in each file that includes the header. GCC 8 will not flag
>this as an error.
> 
>> extern const unsigned int ADD_COLOUR = 0xdfafbf00; boom!  
>
>This normally should not create ADD_COLOUR, just tell the
>compiler that it exists somewhere. So this should result
>in an 'undefined' error.
>
>If OTOH you get a 'multiple definition' error that would
>normally mean there are other definitions as well. Maybe
>you had this in a number of files, decided later to make
>it a single global, and forgot to delete the originals ?
>
>Ciao,
>

Not wishing to hijack this thread but I'm still confused :(

I just did a search of the whole of src. It's *used* about a dozen times
across 5 otherwise unrelated .cpp files, but is only defined here. Just to be
certain, I did a make clean before trying this again, and it's definitely saying
multiple defs

e.g
/usr/bin/ld: CMakeFiles/yoshimi.dir/UI/WidgetMWSlider.cpp.o:(.rodata+0x0):
multiple definition of `ADD_COLOUR';
CMakeFiles/yoshimi.dir/Interface/InterChange.cpp.o:(.rodata+0x1840): first
defined here

This happens at the linker stage.

Also, I thought the whole idea of putting things like this in a #ifndef/#def
block was to ensure it was only set once.

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] G++ trouble

[Will J Godfrey]

On Mon, 16 Nov 2020 13:02:03 +0100
Fons Adriaensen  wrote:

>On Mon, Nov 16, 2020 at 12:24:10PM +0100, Kjetil Matheussen wrote:
>
>> A common mistake in C is omitting extern when declaring a global
>> variable in a header file. If the header is included by several files
>> it results in multiple definitions of the same variable.  
>
>But 
>
>* I _do_ have 'extern' in the header file, and
>* the header file is included in only one .cc file.
>
>Alexandre:
>
>Using 'extern' in a _definition_ seems like a contradiction to me...
>So for now I assume it's a G++ bug.
>
>Thanks to both of you,
>

That's weird.

In GCC 8.3 doing that in a globally included header actually *creates* a
multiple definitions error!

#ifndef GLOBALS_H
#define GLOBALS_H

const unsigned int ADD_COLOUR = 0xdfafbf00; fine

extern const unsigned int ADD_COLOUR = 0xdfafbf00; boom!

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] pugl examples

[Will J Godfrey]

On Sun, 08 Dec 2019 23:38:13 +0100
David Robillard  wrote:

>On Sun, 2019-12-08 at 17:15 +, Will Godfrey wrote:
>> Does anyone know of any simple example files for pugl.
>> I've had a good look around and can't find any. I know there are some
>> fully-formed programs out there, but don't want the confusion of
>> trying to find
>> the core material so that I can understand it.  
>
>The test programs in the source (pugl_test and friends) are about as
>distilled as possible.  The names are a bit misleading, they're really
>functional examples, not unit tests or anything like that.
>
Ah! Thanks for that :)

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] SOLVED Re: Faster boot on Raspberry Pi 4

[Will J Godfrey]

On Wed, 6 Nov 2019 10:24:36 -0500
drew Roberts  wrote:

>On Wed, Nov 6, 2019 at 7:19 AM Will J Godfrey 
>wrote:
>
>>
>> Done with:
>> systemctl disable dhcpd.service
>>  
>
>Do you now have to set static IPs on any interface you want to use?
>
>I use a good amount of Pi boxes and, even when I set a static on either the
>eth or wifi interface, I like to have the other of the two able to get an
>address via dhcp. (This helps with remote troubleshooting.)

I haven't checked that - maybe I should, but this unit should never need to go
online again. It's also in a metal box, so no wireless or bluetooth.

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] SOLVED Re: Faster boot on Raspberry Pi 4

[Will J Godfrey]

Done with:
systemctl disable dhcpd.service

Total time now is 17 seconds.

Thanks for your help.

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Faster boot on Raspberry Pi 4

[Will J Godfrey]

On Wed, 6 Nov 2019 09:25:07 +0100
Jacek Konieczny  wrote:

>On 05/11/2019 23.12, Will Godfrey wrote:
>> I suspect the *actual* delay is connected with networking, but with systemD> 
>> I'm totally lost as to where everything is, so any help would be greatly
>> appreciated.  
>
>Try 'systemd-analyze  blame' then. And check the journal (journalctl -b0).
>
>Jacek

Thanks. That confirmed it. Now to try and find out how to disable it :(

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Click-free fade-in algorithm for synths?

[Will J Godfrey]

On Tue, 24 Sep 2019 19:12:47 -0400
Tim  wrote:

>On 9/24/19 4:26 PM, Paul Davis wrote:
>> 
>> 
>> On Tue, Sep 24, 2019 at 12:38 PM Johannes Lorenz > > wrote:
>> 
>> Counting zero crossings prevents
>> clicking on lower notes, and it makes higher notes more punchy.
>> 
>> 
>> There's fundamentally no such thing as a zero crossing. You might have 
>> two samples on either side of zero, but you still don't have a sample 
>> *at* zero, so in the general case, truncating one of them to zero and 
>> starting/ending there is still going to give you distortion and/or 
>> noise. Obviously there may be cases where one of them is close enough to 
>> zero for this not to be be an issue, but it's not a general method.
>> Ardour applies declick fades every time the transport starts and stops. 
>> You can read about how we do it here:
>> 
>> https://github.com/Ardour/ardour/blob/master/libs/ardour/ardour/disk_reader.h#L135
>> https://github.com/Ardour/ardour/blob/master/libs/ardour/disk_reader.cc#L1445
>> https://github.com/Ardour/ardour/blob/master/libs/ardour/amp.cc#L163  
>
>Hi Paul. Thanks, I was going to mention that.
>
>We had a similar conversation a few years ago when I was adding
>  anti-zipper noise to MusE, and I inquired about zero-crossing methods.
>
>I replied that TV and amplifier electronic volumes use zero-crossing,
>  so why not use it?
>
>But I conceded the very point you mention above, ie. where exactly is
>  the crossing point.
>And it is dependent on frequency so you get a different attack result
>  each time.
>
>In a TV or amp volume chip it's OK but here, meh...
>
>So in the end, looking at the code given above, I can see I did much
>  the exact same thing as Ardour, using a fixed coefficient value
>  driven by time passage (sample rate).
>
>Cheers.
>Tim.


Just like to add, that on a complex waveform with a strong harmonic content it's
quite likely to cross the zero point 2-3 times during each cycle of the
fundamental.

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] jack meterbridge 0.9.2 update / maintenance

[Will J Godfrey]

On Mon, 29 Jul 2019 11:21:39 -0700 (MST)
Stephan Bourgeois  wrote:

>Hi there,
>
>I have been tinkering with Steve Harris' meterbridge 0.9.2 for jack.
>cf. https://github.com/stephanb2/jack-meterbridge
>
>1. Refactored global variables so that the code builds on Debian 9.2.
>2. Improved (?) the dpm IEC scale and ballistics.
>3. Changed the PPM ballistics to use Fons Adriaensen's JMeters algorithm.
>
>I do however have a deeper question: what is the point of jack meterbridge?
>Given that the broadcast and podcast industry has moved to EBU-R128 and
>Ebumeter offers EBU R-128 metering. JMeters offers "nostalgia" PPM and VU
>meters with correct ballistics, more options, better graphics. The only
>thing missing would be a 4x oversampling true peak meter.
>
>Should meterbridge be maintained or should another metering app de bundled
>with jack?
>
>Note that I am not a C engineer, my background is Java and Python. Please
>send code review comments and shout if you see anything horrific.
>
>Let me know your thoughts. 
>Cheers,
>Stephan.

I use it all the time. It is simple, clear and runs well in a standalone
environment. It also acts as a useful summing point. One's ears are the final
arbiter but this is very helpful.

I will check out your build as soon as I have some free time (whatever that is!)


-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Xputty - damn tiny abstraction Layer to create X11 window/widgets with cairo surfaces

[Will J Godfrey]

On Sat, 20 Jul 2019 17:24:47 +0200
Hermann Meyer  wrote:

>However, I've setup a online Documentation for libxputty here:
>
>https://brummer10.github.io/Xputty/html/xputty_8h.html
>
>regards
>
>hermann

And *that* is the best news of the lot!
So many projects have little or no documentation until they are a very long way
into development.

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] 'A' note Tuning Range

[Will J Godfrey]

On Thu, 11 Apr 2019 08:16:29 +
John Rigg  wrote:

>On Tue, Apr 09, 2019 at 09:21:09PM +0100, Will Godfrey wrote:
>> Currently in 'Scales' Yoshimi can set this anywhere between 1Hz and 2kHz, 
>> which
>> is frankly ridiculous.
>> 
>> This doesn't appear at all in the Scala documentation, so that's no guide.
>> 
>> I've had suggestions ranging from +- 1/2 semitone to +- half octave as being
>> more than enough, considering that there is also semitone master key shift
>> covering +- 3 octaves (used to be 5!) along with a fine detune of +63 -64
>> cents.  
>
>A Korg GA-1 tuner can go down to 5 semitones flat. It's quite common
>in the heavier styles of rock music to downtune a few semitones.
>
>John

Interesting. Thanks for that.

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] 'A' note Tuning Range

[Will J Godfrey]

On Tue, 9 Apr 2019 23:23:54 +0200
 wrote:

>Without doubts it should be 440 Hz +- 50 Cent.
>
>+- 50 Cents is what the meter of the BOSS TU-12H chromatic tuner
>displays and what you'll find for other software synth, such as e.g.
>iSymphonic. The BOSS meter's Hz labelling is from 430 Hz to 450 Hz and
>the Hz labelling of iSymphonic from 428 Hz to 452 Hz. IOW the
>Cent labelling range from - 50 Cent to + 50 Cent is a little bit more
>than the HZ labelling range from 428 Hz or 430 Hz to 450 Hz or 452 Hz.
>

Thanks everyone for your comments. There seems to be a general consensus (and
elsewhere too) so I'll check nobody actually *is* using extreme settings for
some reason, and maybe tame it down a bit.

As an aside, doing further reading it seems most authorities consider 5 cents to
be about the limit for people to detect pitch change (lots of caveats of
course) yet Scala example files have figures with 10^-6 cents, and Yoshimi
has 10^-6 :o

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] LAC steaming to c-base, Berlin

[Will J Godfrey]

Well please don't take this as a criticism, but with such short notice the
logistics and costs were just too awkward - especially as now that I'm not
earning I'm trying to work out what my finances are!

So, unfortunately it's no go, but I'll see you on irc. That should be
'interesting' as it's many years since I've used it - apart from an occasional
peek.

On Thu, 21 Mar 2019 19:26:25 +0100
Louigi Verona  wrote:

>Do try though!
>
>
>Louigi Verona
>https://louigiverona.com/
>
>
>On Thu, Mar 21, 2019 at 7:21 PM Will Godfrey 
>wrote:
>
>> On Thu, 21 Mar 2019 18:58:04 +0100
>> Robin Gareus  wrote:
>>  
>> >Hi all,
>> >
>> >A group of people who do not attend the Linux Audio Conference in
>> >Stanford this year are meeting at c-base.org to participate remotely.  
>>
>> Now I'm doubly frustrated :(
>> I'd love to join the group, but the chances of getting travel arrangements
>> and
>> accommodation in place in time are just about zero.
>>
>> I'll try, but as they say, don't wait for me :(
>>
>> --
>> Will J Godfrey
>> http://www.musically.me.uk
>> Say you have a poem and I have a tune.
>> Exchange them and we can both have a poem, a tune, and a song.
>> ___
>> Linux-audio-dev mailing list
>> Linux-audio-dev@lists.linuxaudio.org
>> https://lists.linuxaudio.org/listinfo/linux-audio-dev
>>  


-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Bit shift

[Will J Godfrey]

On Wed, 13 Mar 2019 00:09:17 +0100 (CET)
k...@aspodata.se wrote:

>Will Godfrey:
>> Does anyone know if GCC will replace power of 2 multiplications/divisions of
>> unsigned integers with bit shifts?  
>
>Test on your system:
>
>$ cat a.c
>#include 
>
>int main(int argc, char *argv[]) {
>  uint16_t b = argc * 2;
>
>  return b;
>}
>$ gcc -S a.c 
>$ cat a.s 
>...
>main:
>.LFB0:
>.cfi_startproc
>pushq   %rbp
>.cfi_def_cfa_offset 16
>.cfi_offset 6, -16
>movq%rsp, %rbp
>.cfi_def_cfa_register 6
>movl%edi, -20(%rbp)
>movq%rsi, -32(%rbp)
>movl-20(%rbp), %eax
>addl%eax, %eax
>movw%ax, -2(%rbp)
>movzwl  -2(%rbp), %eax
>popq%rbp
>.cfi_def_cfa 7, 8
>ret
>.cfi_endproc
>...
>$
>
>It seems it just adds the value with itself here.
>
>Regards,
>/Karl Hammar

Thanks, that seems to hold true for a mixture of AMD and Intel machines.

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] MXML V3.0

[Will J Godfrey]

On Mon, 4 Mar 2019 19:45:02 +0100
David Runge  wrote:

>On 2019-03-03 11:56:03 (+), Will Godfrey wrote:
>> Just a heads up for anyone likely to come across this.
>> 
>> It now hides some internal elements that were accessible in V2.x so
>> you might be advised to review your code - it bit us with Yoshimi :(  
>That's unfortunate, but given the CVEs [1] attached to 2.12, I'm also
>kinda glad a new version is out...
>Please release a new version of yoshimi, once you've managed to be
>compatible with 3.0!
>
>Best,
>David
>
>[1] http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=mxml
>

Already done V 1.5.10.2 :)

In view of upcoming changes to MXML we've decided to make a preemptive bugfix
release. At the same time, we've dealt with some memory leaks that might have
occurred when handling corrupted files.


Yoshimi source code is available from either:
https://sourceforge.net/projects/yoshimi
Or:
https://github.com/Yoshimi/yoshimi

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Potential MIDI headaches?

[Will J Godfrey]

On Sat, 19 Jan 2019 21:39:59 +
Will J Godfrey  wrote:

>On Sat, 19 Jan 2019 13:26:55 -0800 (PST)
>Len Ovens  wrote:
>
>>In fact MIDI 2 seems to be a thing mostly for non-kb instruments or computer 
>>generated material (most of which is probably using CV instead of MIDI 
>>anyway).
>>
>>MIDI 1 was huge, My DX7 supported MIDI before the spec was complete. It is 
>>easy 
>>to show off in the music store and sell. I expect the switch to MIDI 2 will 
>>be 
>>a much longer road, very hard to show off from a keyboard.
>>
>>Well thats my opinion anyway.
>>
>>--
>>Len Ovens
>>www.ovenwerks.net  
>
>More details
>https://www.youtube.com/watch?v=iDyXDeLbmeE
>
>I watched this earlier. It seems the MMA have indeed done their homework. MIDI
>1.0 is definitely not going away. The new system will be fully backward
>compatible, and will negotiate for the improvements, falling back to 1.0 if no
>response is seen.
>

Following on, I think our biggest problem is going to be actually getting the
data into a computer. I can't imagine a practical way either ALSA or JACK can
be modified to accept it.

OSC would only work if the data source was sending it, otherwise you'd still
need a translation level within the machine (in which case you might as well
work with the protocol directly). The big synth names are not likely to put any
effort into OSC support, as they have already thrown their hats in for MIDI 2.
I was actually surprised that the MMA managed to get both Apple and Microsoft on
board.

I've now watched that vid. a second time (very much recommend looking at it if
you haven't already) and I'm even more impressed with the way they've designed
the new extensions. Also, to some degree they've split the more 'engineering'
aspects away from the more musician/performance focused ones.

My guess is we've got about 2 years to get up to speed before source instruments
become mainstream. Although I'd like to be involved myself, I really don't think
I've the skills to add anything useful :(

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Potential MIDI headaches?

[Will J Godfrey]

On Sat, 19 Jan 2019 13:26:55 -0800 (PST)
Len Ovens  wrote:

>In fact MIDI 2 seems to be a thing mostly for non-kb instruments or computer 
>generated material (most of which is probably using CV instead of MIDI anyway).
>
>MIDI 1 was huge, My DX7 supported MIDI before the spec was complete. It is 
>easy 
>to show off in the music store and sell. I expect the switch to MIDI 2 will be 
>a much longer road, very hard to show off from a keyboard.
>
>Well thats my opinion anyway.
>
>--
>Len Ovens
>www.ovenwerks.net

More details
https://www.youtube.com/watch?v=iDyXDeLbmeE

I watched this earlier. It seems the MMA have indeed done their homework. MIDI
1.0 is definitely not going away. The new system will be fully backward
compatible, and will negotiate for the improvements, falling back to 1.0 if no
response is seen.

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] You couldn't make it up

[Will J Godfrey]

On Tue, 8 Jan 2019 09:00:16 -0800 (PST)
Len Ovens  wrote:

>On Mon, 7 Jan 2019, Jonathan E. Brickman wrote:
>
>> How about 32bit with 384kHz sampling?  Boxes like these are starting to 
>> spring
>> up. 
>> 
>> https://www.amazon.com/GUSTARD-U12-384KHz-Digital-Interface/dp/B00PU3R6KY  
>
>That box is output only. That seems to be quite common that is there 
>is a consummer interest for output boxes but only niche interest for input 
>or i/o boxes. Input boxes of good quality will cost more as it is easy to 
>build the low gain output analog circuitry but much harder to build high 
>gain, high quality, linear, controlable (with accuracy) input circuitry. 
>For a scope, knowing the exact level at each gain position is pretty 
>important.
>
>--
>Len Ovens
>www.ovenwerks.net

I was afraid it would be too good the be true :(

You're quite right that the linearity needs to be good and at high gain,
however I'd be inclined to use a passive 20dB per step attenuator on the front
to maintain a good overload margin.

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Is -ffast-math safe for audio?

[Will J Godfrey]

On Thu, 22 Nov 2018 19:28:58 +0100
David Runge  wrote:

>On 2018-11-22 18:57:15 (+0100), Hermann Meyer wrote:
>> In the guitarix project we've disabled  -ffast-math several years ago,
>> when I remember right it was at gcc3, as it could lead to different
>> un-reproduciable calculations. Last option I've disabled on gcc8 now,
>> is -ffinite-math-only, this one leads to nan's and inf's in several
>> cases, which been as well not reproducible.  
>Rabbit hole stuff! SuperCollider came to a similar conclusion:
>https://github.com/supercollider/supercollider/issues/4116


Thanks a lot people. I kept thinking I was doing something wrong!

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] LAM

[Will J Godfrey]

On Tue, 20 Nov 2018 16:42:44 -0500
Ivica Ico Bukvic  wrote:

>There is also a COMPEL project that I am currently heading and which is 
>designed to facilitate interfacing between composers and performers. It 
>offers preservation of both performances (archiving) and the materials 
>for the necessary reproduction of the work itself, including software. 
>The platform offers multiple licensing options from fully open source to 
>commercial and is therefore completely license-agnostic (all copyrights 
>remain with their owner). It is hosted by my university and in the 
>coming weeks we are preparing for the soft-launch. It supports 
>groups/collections and is based on the leading open-source 
>preservational platform developed by the network of libraries worldwide. 
>Please let me know if you are interested in this and I will gladly keep 
>you posted.
>
>Best,
>
>Ico
>
>
>On 11/20/2018 10:14 AM, Thomas Brand wrote:
>> On Sun, November 18, 2018 09:22, Will Godfrey wrote:  
>>> Linux Audio Music has been dormant for a very long time, but recently I
>>> contacted the the person who hosted and ran it.
>>>
>>> The reason he closed it was because of a serious vulnerability was
>>> discovered in Rails, and he no longer had time to do the necessary
>>> upgrades.
>>>
>>> However, he has told me that he still has the entire database and the
>>> code. In his own words: "... would be happy to host and do what I can to
>>> facilitate a handoff to someone else who wants to manage it."
>>>
>>> For anyone who doesn't know, this was a relatively simple and clean site
>>> aimed specifically at providing a home for tracks composed with Linux -
>>> something rather rare!
>>>  
>> How many tracks are currently "homeless", how many gigabytes? I guess the
>> code would be hard to re-use. Tracks could be moved relatively easy to
>> another place if metadata is clean.
>>
>> Greetings
>> Thomas

Some very interesting responses, and I like this the most. It would be good to
be able to fetch the existing material from Hans.

Hmmm. Thinking about it, I really can't remember if it was actually stored
music, or links to other sources. If the latter, much of it may now be
missing :(

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] LAM

[Will J Godfrey]

On Mon, 19 Nov 2018 09:52:31 +0100
Louigi Verona  wrote:

>Completely agree with Daniel here. And Soundcloud or even a YouTube channel
>(or both) are far more accessible to listeners as well.
>
>Louigi Verona
>https://louigiverona.com/

Soundcloud no longer has groups, They removed then with no discussion and very
little warning a couple of years ago.

Youtube is a flytrap and slowly increasing it's use of forced advertising.

'Easier' is not necessarily 'Better' :(

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] MIDI-2-TCP, TCP-2-MIDI

[Will J Godfrey]

On Sun, 2 Sep 2018 07:52:48 +0200
Ralf Mardorf  wrote:

>On Wed, 29 Aug 2018 13:00:07 -0700 (PDT), Len Ovens wrote:
>>MIDI was designed to handle in realtime (10 events from 10 fingers)  
>
>PS: Even if we reduce MIDI to one channel for real-time playing without
>usage of e.g. the nose as an eleventh finger, at least usage of pedals
>is included. The amount of data send by just one pedal easily exceeds
>what a human could do with ten fingers on black and white keys. A
>keyboarder could use one hand to control a joystick (e.g. pitch bend and
>modulation at the same time) and two feet to control two pedals and at
>the same time use 5 fingers to play black and white keys with after
>touch. The MIDI standard allows to do this.

As a matter or interest, the only time I've had missing noteoffs with
standard MIDI was when I had only a single MIDI port, and daisy-chained a sound
canvas and two keyboards (both sending active sensing). One for the
keyboards also had a pedal attached. Having said that I always used good quality
short cables.

These days, I have a 4 port USB MIDI unit, and run the same hardware along with
a substantial controller and one pedal + two foot switches - narry a problem,
and no noticeable jitter with live playing.

Just my 2d {old money}

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Do professionals use Pulse Audio? ; xfce4-mixer

[Will J Godfrey]

I use one machine specifically for music, permanently connected to Keyboards
etc. and PA was removed with extreme prejudice. On the audio side it's working
entirely Jack - MIDI is mostly ALSA.

On my other 'office' machine it's there and I don't pay any attention to it.


-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Some news and Linux Audio Programmer job position at MOD Devices

[Will J Godfrey]

On Wed, 7 Mar 2018 23:41:56 +0100
Gianfranco Ceccolini  wrote:

>Greetings gentlemen
>
>It has been quite some time since I last wrote here.
>
>Please forgive me for using this channel for such communication but we have
>some news that are particularly interesting for this community in special.
>
>MOD Devices is growing. You can read a bit here:
>
>https://forum.moddevices.com/t/mod-devices-is-growing-up/2140
>
>We're opening a job position specifically targeted to Linux Audio. Since
>this is the place were most of the matching profiles communicate, I thought
>it might be a good place to publish it here.
>
>https://drive.google.com/file/d/1HKdWwhjeSPWywu-3gasz7OThbUClQ7dq/view?usp=sharing
>
>Please contact us if interested and feel free to pass on to friends from the
> Linux Audio community that you think might be interested.
>
>Best regards
>
>Gianfranco Ceccolini
>+49 160 646 9313
>+49 030 555 70435
>gianfra...@moddevices.com
>
>MOD Devices
>Wilhelm-Kabus-Straße 21-35
>10829 - Berlin

Very good news indeed.
I hope you quickly find the person with the right skills... and attitude :)

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Will J Godfrey]

On Sat, 9 Dec 2017 13:37:30 +
Gordonjcp  wrote:

>On Sat, Dec 09, 2017 at 02:24:37PM +0100, Louigi Verona wrote:
>> This is a good point, Fons.
>> 
>> On Windows it is typical to bundle a program with stable libraries and
>> dependencies. Is this strategy thinkable on FLOSS systems?  
>
>No, and it's a stupid idea on Windows too, which is why Windows uniquely
>suffers from "DLL Hell".
>
>Just write your software so it doesn't break APIs.

I rather thought it was library API changes that were breaking the software -
something I've been a victim of.

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] DSP transients

[Will J Godfrey]

On Sun, 3 Sep 2017 10:59:53 -0400
Mark McCurry  wrote:

>On Sun, Sep 3, 2017 at 10:19 AM, Harry van Haaren  
>wrote:
>> This won't tell you *where* in the code the issue is - but does give you a
>> reproducable test
>> case and some input on if DSP load is consistent. If you want to know
>> *where* in the code most of
>> the time is spent, then using linux perf tools or similar might be useful.
>
>If something more fine grained is desired I had some luck using valgrind to 
>dump
>detailed statistics for every execution of the audio process() callback.
>Valgrind will tell you where the problem is as long as it's CPU bound and
>not memory/IO bound operations causing the issue.
>This was pretty helpful for smoothing out some of the overhead that
>ZynAddSubFX had
>in older versions.
>The writeup is somewhat rough, but my old notes for using valgrind to profile
>transient CPU load are stored at:
>http://log.fundamental-code.com/2013/09/07/profiling-realtime-code.html
>
>--Mark

Thanks for the suggestions guys. I was rather hoping for something more
lightweight than Valgrind - last time I tried it (OK a couple of years ago) I
had horrendous problems - any form of stability even at 4096 frames was
debateable.

However I'm pleased to say running it today with the arguments suggested by
Mark was rather different (although I did have to run at 1024 frames to get the
Xruns down to a few handfulls). It's going to take me some time to work out how
to interpret them results though :(

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] DSP transients

[Will J Godfrey]

On Sun, 3 Sep 2017 13:35:47 +
Fons Adriaensen  wrote:

>On Sun, Sep 03, 2017 at 08:50:08AM +0100, Will Godfrey wrote:
>
>> Does anyone know of software that can log these without significantly adding 
>> to
>> the load itself?  
>
>What do you call a transient in this context ???
>
>
>Ciao,

I'm particularly wanting it investigate the behaviour at note-on. If possible,
the absolute peak relative to the background working level. Also the 'shape'.
Is it a flat topped lump, or a narrow spike over a few samples rapidly fading
down.

I'm hoping that if I can see and (hopefully) understand exactly what is
happening it will help me work out how to mitigate it, and indeed if changes
are really improving the situation. Currently my only form of test is to run at
the edge of getting Xruns - very many times :(


-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Mixed boolean & numbers

[Will J Godfrey]

On Wed, 31 Aug 2016 21:28:45 -0400
David Robillard  wrote:

> On Sat, 2016-08-27 at 16:49 +0100, Will Godfrey wrote:
> > I'm finding quite a lot of occasions where variables defined as 'bool' are
> > sometimes being set with true or false and other times 0 or 1. On one 
> > occasion
> > there is something like x = n + {boolean variable}
> > 
> > This last one seems quite unsafe to me as I didn't think the actual value of
> > true and false was guaranteed.
> > 
> > Am I being overly cautious or should I change them all to one form or the 
> > other?  
> 
> This is fine.  The C/C++ standards guarantee that a bool, when converted
> to an integer, is 1 or 0 (the pedantically correct way of saying this
> depends on which standard/revision, but effectively that sums it up).
> 
> It's pretty convenient/elegant at times.  Personally, I exploit it when
> that's the case, but be more explicit if it has potential to be
> confusing.

Thanks again for the info.


-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Jack ringbuffer

[Will J Godfrey]

On Thu, 10 Dec 2015 06:51:48 -0800 (PST)
Len Ovens  wrote:

> On Thu, 10 Dec 2015, Will J Godfrey wrote:
> 
> > On Thu, 10 Dec 2015 09:07:25 -0500
> > Paul Davis  wrote:
> >
> >> On Thu, Dec 10, 2015 at 9:04 AM, Will Godfrey 
> >> wrote:
> >>
> >>> If I have a buffer size of 256 and always use a 4 byte data block, can I 
> >>> be
> >>> confident that reads and writes will either transfer the correct number
> >>> of bytes or none at all?
> >>>
> >>
> >>
> >> You cannot.
> >
> > Somehow I expected that would be the answer :(
> >
> > So, if I get, (say) three bytes processed, presumably I make another call 
> > for
> > just one.
> 
> You can check if there are 4 bytes available, if not don't read (yet). 
> Normally (at least for anything I have done) the reason I use the ring 
> buffer is to divorce the data processing from any real time requirement. 
> So I am reading the ring buffer in a loop, I can check how many bytes are 
> available. jack_ringbuffer_read_space(buffer) can be used I think.

I'm doing this. My main concern was whether the pointers would be updated in
byte steps or block size steps, and what implications that might have.

I'm quite prepared to believe I might be over-thinking the problem. This has
been known before :)

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Jack ringbuffer

[Will J Godfrey]

On Thu, 10 Dec 2015 09:07:25 -0500
Paul Davis  wrote:

> On Thu, Dec 10, 2015 at 9:04 AM, Will Godfrey 
> wrote:
> 
> > If I have a buffer size of 256 and always use a 4 byte data block, can I be
> > confident that reads and writes will either transfer the correct number
> > of bytes or none at all?
> >
> 
> 
> You cannot.

Somehow I expected that would be the answer :(

So, if I get, (say) three bytes processed, presumably I make another call for
just one.

Is it safe to cheat and without modifying the data block adjust the
byte count and increment the pointer passed to jack by the appropriate amount?

I'm thinking that I should only make two or three repeat attempts before
aborting.

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Integer performance

[Will J Godfrey]

On Sun, 03 May 2015 21:36:25 +0200
Florian Weimer  wrote:

> * Will Godfrey:
> 
> > Just a curious thought...
> >
> > If you are using only small values is there really any benefit in
> > using chars and shorts rather than just using integers everywhere
> > and letting the compiler sort it out?
> 
> Many languages do not actually support arithmetic on chars and shorts,
> but promote them to ints first.

Currently I work in C and C++. I don't see that changing any time soon. They are
more then enough to keep me occupied!

> It is usually beneficial to use the smallest possible data type for
> arrays because it cuts down memory use and increases the number of
> array elements which fit into the CPU caches.

Good point. I didn't think of that.

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Advanced Gtk+ Sequencer aka GSequencer now on GitHub

[Will J Godfrey]

On Fri, 3 Apr 2015 15:37:27 -0400
Paul Davis  wrote:

> On Fri, Apr 3, 2015 at 3:35 PM, Will Godfrey 
> wrote:
> 
> >
> > From the hardware viewpoint SysEx events can be effectively infinite. The
> > header contains the number of bytes in the block, so the number
> > representation
> > limits the block size,
> 
> 
> not true. sysex messages do not contain a size/byte count. the message
> content may include it, but that is not part of the sysex spec.

I stand corrected.

I'd seen it in both Yamaha and Roland manuals and obviously made an invalid
assumption :(

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] A bit more MIDI clarification please

[Will J Godfrey]

On Sun, 5 Oct 2014 14:58:36 -0400
Paul Davis  wrote:

> On Sun, Oct 5, 2014 at 2:27 PM, Will Godfrey 
> wrote:
> 
> >
> > But, what happens if the synth was registered with jack before the
> > sequencer?
> > Presumably it is now going to get it's MIDI data *after* it has already
> > processed that callback.
> 
> 
> JACK clients are executed in the order required by their interconnections.
> If client A *sends* data to client B, then client A will always execute
> before client B.

Thanks. That's a relief. I'd got the impression they were executed in the order
they were first registered.

> if you're silly enough to create a feedback loop, then the  order becomes
> undefined.

Never even thought of trying to do that!

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Some questions about the Jack callback

[Will J Godfrey]

On Sun, 21 Sep 2014 16:51:26 -0400
Paul Davis  wrote:

> On Sun, Sep 21, 2014 at 4:31 PM, Will Godfrey 
> wrote:
> 
> > ually...
> >
> > This might seem a bit obvious, but am I right in thinking that while jack
> > collects the current inputs it is at the same time pushing out the
> > *previous*
> > bufferful of data - hence latency.
> >
> 
> you're wrong. sort of.
> 
> the simplest way to think about this is with the double buffered model that
> ASIO enforces, which in ALSA is equivalent to 2 periods.
> 
> while the audio interface is (playing|capturing) one buffer/period, JACK is
> (collecting|delivering) data for the other. when the audio interface is
> finished, we flip so that the h/w is now working with the buffer/period's
> worth data that JACK just finished with (i.e. either playing it or
> refilling the capture part), and meanwhile JACK is again
> (collecting|delivering) data to its clients. and on and on it goes.
> 
> thus, if JACK is not done (collecting|delivering) data by the time the
> audio interface is ready to flip ... xrun.
> 
> the latency comes from the fact that in a block-structured handling model
> like this, the output played by the audio interface can under NO
> circumstances ever be based on anything earlier than the previous
> buffer/period. audio data that arrives at the audio interface will get
> delivered to JACK at some point in the future, JACK clients will do
> something with it (e.g. playing it back as-is) and then 1 buffer/period
> after it became available to JACK (and its clients), it is available to the
> audio interface to playback again.


OK.
Got that. Thanks for the explanation.

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Some questions about the Jack callback

[Will J Godfrey]

On Fri, 19 Sep 2014 17:36:00 -0400
Paul Davis  wrote:

> On Fri, Sep 19, 2014 at 5:32 PM, Paul Davis 
> wrote:
> 
> >
> > Say we have A, B & C in that order and B&C each take 3mS to return but A
> >> takes
> >
> > 6mS. Does C get booted out even though it was A that was the time hog?
> >>
> >
> note that nobody but the user can know that A is the time hog. A could be a
> huge but very efficient signal processor and C could be a badly written
> delay line. The amount of time they take relative to what they "should"
> take is not known to JACK (and in most cases, not even to the user).

Thanks Paul. This makes perfect sense, and again is more-or-less what I'd
guessed. It basically underlines that a client really can't make any
assumptions :(

If a client fails to send anything to the buffer, is it likely to contain just
random data, zeros or the last block of data the client sent?

This may be a bit over the top, but I'm thinking along the lines of a client
knowing it will take (say) 5mS to fully process but only having 2mS available
and deciding to just return a sort of approximation instead.

It's probably not worth the effort, but I wondered if the client could attempt
to be a 'good citizen' and take some form of remedial action.

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] QmidiNet 0.2.0 is out!

[Will J Godfrey]

On Fri, 20 Jun 2014 20:31:24 -0400
Paul Davis  wrote:

> On Fri, Jun 20, 2014 at 7:35 PM, Brett McCoy  wrote:
> 
> >
> > Negligible. I've been using it (and multimidicast previously) for
> > years, since I use samplers on a separate machine from where I
> > sequence, much better than old serial MIDI cables, too, since you can
> > have multiple MIDI interfaces over a single ethernet interface (and
> > can be used for wireless also, like with TouchDAW)
> >
> 
> and moreover, you can have multiple computers "connected" to the same
> controller without moving any cables. i don't mean simultaneously, but if
> you use computer A then computer B and they are both on the same network,
> they both can communicate with the controller without any replugging. a
> small but lovely thing. it would have been lovely if apple (cough, cough)
> had adopted this also but they rolled their own solution.

Thanks for all the info. This does indeed look seriously impressive.
However, I think I should probably asked in LAU!

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Ring buffers again

[Will J Godfrey]

On Thu, 22 May 2014 17:03:52 -0400
Paul Davis  wrote:

> On Thu, May 22, 2014 at 4:46 PM, Will Godfrey
> wrote:
> 
> >
> > As well as the jack ring buffer, I've looked at several others now, and
> > their
> > example code. The most significant thing that seems to be different about
> > them
> > (from a usage point of view) is the way they handle overflows. However, if
> > the
> > buffer size is defined as an exact multiple of the data type/structure and
> > only
> > complete structures are pushed or popped, would I be right in thinking
> > that you
> > would only need to check on an all/none basis?
> >
> > Have I missed something that could cause a partial data transfer?
> >
> 
> the jack ring buffers are byte-oriented, so you do have to be careful.
> however, if both the reader and writer only ever increment their respective
> pointer/index in multiples of the same basic byte count, then you should be
> OK.
> 
> if you use a C++ template ring buffer, then you necessarily cannot get
> partial transfers.

Thanks. It seems I'm on the right track then :)

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] New kid on the block

[Will J Godfrey]

On Thu, 10 Apr 2014 14:10:23 -0400
David Robillard  wrote:

> On Wed, 2014-04-02 at 20:47 +0100, Will Godfrey wrote:
> [...]
> > Also - and I don't know if this is actually a realistic situation - how 
> > would I
> > handle an all alsa setup? Would there be anything preventing me just 
> > linking to
> > the ring buffer itself?
> 
> It's just a ringbuffer, little thing.  If you're concerned about a
> dependency you can just copy the Jack one or choose from any number of
> others floating around the web.
> 
> Here's my two, in C and C++ flavours, FWIW:
> 
> http://svn.drobilla.net/zix/trunk/zix/ring.h
> http://svn.drobilla.net/zix/trunk/zix/ring.c
> 
> http://svn.drobilla.net/lad/trunk/raul/raul/RingBuffer.hpp
> 
> Last I checked, these, the Jack one, and the one(s) in Ardour are doing
> the same things as far as barriers and correctness are concerned.  I
> can't rigorously claim they are correct, but they seem correctish and
> several people have hammered on them with many threads with no
> observable error.
> 
> There was a test suite / ringbuffer shootout (by Olivier Guilyardi and
> subsequently tinkered with by others) called "rbtest", but the
> repository seems to have fallen off the face of the Internet and I can't
> find it anymore.
> 
> Cheers,

Thanks a lot David. That was most helpful.

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev