Re: [LAD] ALSA Sequencer timestamp on event without

uot;clocks" which are synced (no doubt with some allowance for drift and jitter), then in this example it appears it is the sender that needs fixing. > Thus we need somehow to set the event timestamp to any arbitrary value. Is this fixing the issue, or

Re: [LAD] making sense of Jack MIDI; or, is this an appropriate use

Message: 7 Date: Sun, 17 Feb 2013 17:10:11 -0500 From: Paul Coccoli < pcocc...@gmail.com> >You're effectively serializing your object and passing them over the ringbuffer. If you do it this way, you should at least consider explicitly embedding the type and length

[LAD] : What KvR didn?t understand. [OT]

>From: "Patrick Shirkey" >With his insistence that he is a godly person while also being so >aggressive it seems he has a few issues to work out which could also be >the cause of his obvious substance abuse. However it could be that he is >just responding to his social environment. Maybe he is fr

Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO)

> I think the most reasonable standard for an absolute 1/oct > frequency unit is 0.0 = 440Hz My modular plugins use a reference of 440Hz. Also parameters are ranged between 0.0 - 10.0 but can exceed that if need be. (in a modular synth, everything needs to interoperate). So for frequency 5.0 is 4

Re: [LAD] LV2 Achievement of GMPI Requirement

> > My concept with GMPI (not everyone agreed) was that MIDI was not > > required *in* the plugin. > > I decided the *host* should provide that routine (mapping MIDI to port value). Written once, > > available to every plugin developer. > This is almost exactly what I proposed as an LV2 extensi

Re: [LAD] LV2 Achievement of GMPI Requirements

> I think you are in error considering these things mutually exclusive. > Yes, hosts dealing with MIDI binding is how things should be done, but > crippling a plugin API to not be able to handle MIDI is just that: > crippling. Maybe I want to patch up a bunch of plugins to process MIDI > events, o

Re: [LAD] LV2 Achievement of GMPI Requirements

> > For historical interest. I did complete the GMPI prototype. > I don't suppose the code for those modular synthesis plugins is > available? :) I release as many as possible open source. Unfortunately before I used plugins I coded everything as part of my application, so a most of the good filt

Re: [LAD] LV2 Achievement of GMPI Requirements

eal by many, and still is). My suggestion that it didn't need MIDI at all (MIDI being too limited and crufty) resurfaced in VST3 Note-expression. What we see now with LV2, SEM and VST3 is a vindication of GMPI actually being ahead of its time. Jeff McClintock www.synthedit.com B

Re: [LAD] Plugin buffer size restrictions

> From: David Robillard > > I'm a modular head, I remain convinced that control ports are nothing > but a pain in the ass and CV for everything would be a wonderful > fantasy land :) It's called "SynthEdit land" *everything* is CV ;) (not on Linux sorry). > As it happens, I am currently portin

[LAD] : Plugin buffer size restrictions

> I think providing synchronous control events, with 'future' values (at > least some distance L in the future) is the way to get that. Let's > pretend that the Ultimate Plugin Interface (UPI) 1.0 exists, works this > way, is stable and unmalleable, and all you have to work with to > deliver > you

Re: [LAD] Plugin buffer size restrictions

> From: Fons Adriaensen > Subject: Re: [LAD] Plugin buffer size restrictions > On Mon, May 28, 2012 at 06:05:20PM +0300, Stefano D'Angelo wrote: > > > IMO it's easily said: if control rate < audio rate it's plugin's > > responsibility, otherwise the host feeds upsampled/filtered control > > sign

Re: [LAD] Plugin buffer size restrictions

> I assume that computing parameter trajectories basically means > interpolating, and that inevitably introduces some latency. That's a key point. Interpolating any sampled signal introduces latency. > let the host pass a limited number of future parameter samples at each > run() (could be negoti

Re: [LAD] LV2-C++-Tools

> > "Shared data plus locking" is a pretty crap model in general, really. > > When people talk about all the complications that threads introduce, > > they're really talking about this. Shared mutable state is the > cancer of multi-threaded programming. This should be tattooed on every newbie. ;)

Re: [LAD] Linux Malware

> Lignux systems only have write access to their home directories, which > the system does not run software from by default. So Malware can trash your personal documents and steal your identity.but the kernel is safe? > Windows isn't a victim of its own popularity, it's a victim of being > cr

Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out! (Emanuel

> The chance for MIDI to improve seems very low, due to its technical > limits. HD-Protocol MIDI is coming, albeit with painfully slow progress. Best Regards, Jeff ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linu

Re: [LAD] sliders/fans

> In other words, you'd expect such a system to behave as if you > had two faders in series. > > Now if the DSP code only sees the sum of the two values (as it > should, having a VCA group is just a user interface issue), Ah, You just contradicted yourself. If you expect the system to behave like

Re: [LAD] Conciderations of Design

David's advice is right on. > why not use audio rate control ports? Or some sort of hybrid, allowing > you to > switch as needed - but that quickly becomes a complexity explosion... I use a hybrid where ports are audio-rate AND each port has two states: 'streaming' or 'static'. So if you don't wa

Re: [LAD] Internally representing pitch : A new approach

Don't base anything on 7-bit MIDI, it's too low-fi for a modern system, plus it's keyboard-centric (i.e the concept of each note 'stuck' at a single pitch is too restrictive). Plus it's being replaced by hi-def MIDI. My suggestions: * Use at least 32-bit floating point to represent pitch to give h

[LAD] LAD] RT-Safe UI/Engine Decoupling using Functional

sor become more common in studios. Surly passing functors (which are pointers?) to audio code running in a separate address space can not work? Jeff McClintock > From: Florian Paul Schmidt > Subject: [LAD] RT-Safe UI/Engine Decoupling using Functional > Programming and Referen

Re: [LAD] Android audio plugins

> From: Nick Copeland > Don't you think it is more likely that people who are interested will run > Linux as a replacement for Android on the ARM tablets rather than have > the apps ported over? "Smartphone growth is on a meteoric rise, with Android leading the way... Android follows with 14.5%,

Re: [LAD] [ann] CAPS 0.4.5

> An informal experiment shows that jack-rack 1.4.7 and ardour 2.8.11 > both do exactly the right thing when a plugin referenced by a saved > session gains a port: they set the new port to its default value and > happily carry on working. > > (Both also cope with the removal of a port. These are

Re: [LAD] [ann] CAPS 0.4.5

> All plugins with the same URI MUST be compatible in terms of 'port > signature', meaning they have the same number of ports, same port > shortnames, and roughly the same functionality. URIs should probably > contain a version number (or similar) for this reason. > > Rationale: When serializing s

Re: [LAD] Linux-audio-dev Digest, Vol 49, Issue 16

> I'd be interested to hear how various projects handles this internally, if > anybody wants to chip in? In mine, each parameter has two additional members: - controller_id (32 bit int) - SYSEX string. (for SYSEX based automation). Controller ID is several sub-fields. The high order 8 bits are th

Re: [LAD] Linux-audio-dev Digest, Vol 49, Issue 6

The host is free to provide as few or as many options as it needs. That one example of thinking in a platform independent way, without being absurdly hard to implement, in fact real easy. Jeff McClintock ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Portable user interfaces for LV2 plugins.

> From: Paul Davis > Subject: Re: [LAD] Portable user interfaces for LV2 plugins. > VST3 allows the GUI to run in a different process? " The design of VST 3 suggests a complete separation of processor and edit controller by implementing two components. Splitting up an effect into these two parts

Re: [LAD] Portable user interfaces for LV2 plugins.

he only way to do automation and state recall right. Best Regards, Jeff McClintock. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Calculate R M S (Alfs Kurmis)

> From: Fons Adriaensen > On Fri, Feb 18, 2011 at 07:36:44AM +1300, Jeff McClintock wrote: > > > With a RMS VU Meter you measure a 1KHz tone as a reference. > > A contradiction... A VU does not measure RMS, whatever does measure > RMS is not a VU. Isn't a VU Mete

Re: [LAD] Calculate R M S (Alfs Kurmis)

With a RMS VU Meter you measure a 1KHz tone as a reference. Best Regards, Jeff ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] on the soft synth midi jitters ...

>> BUT never ever a licenced Windows + a bought Cubase will cause such an >> issue, assumed you didn't install a cracked Windows Office too. >clearly you have no idea who Jeff McClintock is, or you wouldn't be offensive. ;) I do use licensed software. I am quite

Re: [LAD] on the soft synth midi jitters ...

> It could be useful to have some anecdotal evidence to quantify measures > of jitter like "annoying" and "drunk", so: > > What is your buffer-size? Hi Jens, I test with several sound cards. M-Audio, Creative Audigy, ASIO-for-all, and generic motherboard driver. I've found the jitter at settings

Re: [LAD] on the soft synth midi jitters ...

r writing my own plugin standard, sample-accurate MIDI is no more difficult to support than block-quantized MIDI. Jeff McClintock > Message: 8 > Date: Tue, 5 Oct 2010 21:22:23 +0100 > From: Folderol > Subject: Re: [LAD] on the soft synth midi jitters ... > To: linux-audio-dev@

Re: [LAD] [LAA] announcing envy24control, mudita (*) edition.

> > Real detents require force feedback. A mouse doesn't > > provide that. This GTK thing is completely broken. Logitech iFeel mouses..would be cool if supported .. http://www.dansdata.com/ifeel.htm ___ Linux-audio-dev mailing list Linux-audio-dev@lis

Re: [LAD] Linux-audio-dev Digest, Vol 40, Issue 28

n 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. ___ Linux-audio-dev mailing list Linux-audi

Re: [LAD] Qt GUI for LV2 Plugin

> > wait, isn't the > > LV2UI_Descriptor->port_event() and LV2UI_Write_Function() interface > toolkit > > agnostic? Wouldn't it be possible to have toolkit agnostic host- > facilitated communication? > > Yes, these are. And these allow plugins to communicate > with other plugins. > > However, th

Re: [LAD] minimal LV2

me and time again. It's a bad design. Jeff McClintock. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] successive note on midi events

> A string of note-ons following each other all for the same pitch n without > any intervening note-offs for pitch n, IS PERFECTLY ACCEPTABLE provided > they are INTENTIONAL and NOT accidental. No. MIDI note-on represents a key press. Note-OFF - key release. There is no logical way a key can be

Re: [LAD] Linux-audio-dev Digest, Vol 37, Issue 24

a specific note while it's playing. You can play two voices in unison. These features takes pages of code in my MIDI synths. Microtuning is seldom supported by soft-synths. With your model it's difficult NOT supporting it. Jeff McClintock _

Re: [LAD] automation on Linux (modular approach)

ough to realise that MIDI already supports very flexible note control. MIDI's significant flaw is it's grossly outdated 7-bit resolution, the underlying voice model is sound. > Virtual voices are used by the "sender" to define and > address contexts, whereas the actual

Re: [LAD] automation on Linux (modular approach)

> There is no way to refer to anything higher level, to say e.g. this is a control message for note #12345 that started some time ago" could be done by using SysEx. FYI MIDI sysex does support that already [UNIVERSAL REAL TIME SYSTEM EXCLUSIVE] KEY-BASED INSTRUMENT CONTROL F0 7F 0A 01 0n kk

Re: [LAD] GMPI

From: Paul Davis > # In-place processing (reusing an input buffer as an output buffer) must be supported by GMPI. Not critical, in fact VST has removed this feature. Possible future enhancement. >say it ain't so jeff! This is a ridiculous bit of cache thrashing. I haven't followed VST carefull

Re: [LAD] GMPI

>From: Chris Cannam On Sun, Nov 8, 2009 at 6:41 AM, Jeff McClintock wrote: > GMPI is quietly and successfully in use as the new native plugin format of > SynthEdit. >Interesting. Can you link to an API reference or the like? Hi Chris, The download link is below. The curren

Re: [LAD] How to develop guis for LV2?

>-dr GMPI is quietly and successfully in use as the new native plugin format of SynthEdit. I've so far written 70 plugins with it, and others are writing more. SynthEdit's previous plugin format has about 1000 plugins available, hopefully also will be ported to GMPI (aka SEM V3)... so GMPI can'

[LAD] : "Open midi-keyboard"

> > > features would you like to see, what are you missing from > > > off-the-shelf products? Hi-Definition MIDI support. Jeff ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-aud

Re: [LAD] the role of lv2 extensions

elf accordingly. I don't need to support changes 'on the fly' while the plugin is processing audio (which could be difficult to perform within the constraints of realtime operation (without memory allocation etc). So you can avoid the nasty realtime issues, yet easily support run-t

Re: [LAD] Impro-Visor created on sourceforge

ttribution. The GPL people objected, calling it the "obnoxious BSD advertising clause ... and forced this clause removed. So it's fair to say the GPL does NOT require attribution. Jeff McClintock ___ Linux-audio-dev mailing list Linux-audio

Re: [LAD] Linux-audio-dev Digest, Vol 29, Issue 7

Hi Chris, > > " 3.4 ?Install any non side-by-side shared files to the correct > locations > I've only just got around to reading this properly, but it seems to be > saying the opposite of what you said -- it seems to be saying that > components that are shared across multiple vendors (such as aud

Re: [LAD] RFC: Default discovery paths for LADSPA, LRDF, LV2 and DSSI (and more?)

> From: Chris Cannam > On Thu, Jun 25, 2009 at 9:13 PM, Jeff McClintock > wrote: > > Windows has official rules for this. ?Users are no longer allowed to > add > > random files to an application's directory in "/Program > Files/Appname". > >

Re: [LAD] RFC: Default discovery paths for LADSPA, LRDF, LV2 and DSSI (and more?)

iles/Appname" at install time only (because the installer has elevated privilege). User installed plugins go in CSIDL_PROGRAM_FILES_COMMON , e.g. typically "C:\Program Files\Common Files\LADSPA Plugins..." Best Regards, Jeff McClintock __

[LAD] VST 2.4 v. 3.0

> does anyone have any idea on the uptake of VST 3 ? Seems only VST3 works well on 64-bit systems. (VST 2 is supported, but runs in a high-latency 32-bit emulation environment). My hunch is VST3 uptake will track 64-bit Windows uptake. Jeff > Is this becoming the standard and 2.* being quickly

Re: [LAD] "enhanced event port" LV2 extension proposal

>> All of MIDI can be reduced to two messages: set-control (addressed by >> Channel, Voice and Controller ID) .. and SYSEX - for data-dumps. >What you say is of course a true statement, but it is ignoring what the >founding fathers of MIDI attempted to accomplish regarding efficiency on >a bandwit

Re: [LAD] "enhanced event port" LV2 extension proposal

MIDI remains stupid. MIDI is 15 different ways of saying "set this control". All of MIDI can be reduced to two messages: set-control (addressed by Channel, Voice and Controller ID) .. and SYSEX - for data-dumps. Jeff McClintock Message: 13 Date: Fri, 30 Nov 2007 00:30:58 + Fr

Re: [LAD] Terminology problem

>Maybe... I considered Control as well, but to me, both of those sound more like single instances of something (just like Ports), rather than the Class/Type style (ie "Voice Pitch Controls") term I'm looking for. >*Some* plugin API or something somewhere must have something similar to this, I'

Re: [LAD] LADSPA dilemma

Since LADSPA does not specifiy that control values are valid at activate(), either As a host developer, I'd like to explain why control values are not valid at activate(). Imagine a modular plugin system which allows chaining of control signals. Assume all plugins are activated before any is