Re: [LAD] MIDI 2.0 is coming
On Tue, 29 Jan 2019 13:37:01 +0100 (CET), Jeanette C. wrote: >why should I use Linux and LV2 plugins, if they don't work with my >$1000 control keyboard? There's always hope. From the link posted by Louigi: "[snip] With previous MIDI feature additions, the challenge has often been getting companies to actually implement it. Take MPE [1] as an example – despite being officially adopted in 2018 to the MIDI spec, only a handful of companies (like ROLI and Moog) have added it to commercial products [snip]" [1] From https://www.midi.org/articles-old/midi-polyphonic-expression-mpe: "[snip] Music making products (such as the ROLI Seaboard, Moog's Animoog, and Apple's Logic) take advantage of this so that musicians can apply multiple dimensions of finger movement control: left and right, forward and back, downward pressure, and more. [snip]" I mentioned the Animoog's touch screen feature in the the LAU thread about Dominique's DIY Theremin. A song that still is in progress has short parts with something similar to a Theremin played via touch screen, using the Animoog. It's impossible to record by MIDI now, maybe Logic could do, but neither the iOS, nor the Linux software I'm using is able to record and play it via MIDI. I guess that Animoog even doesn't send the required data. I had to record it as an audio track over and over again. However, even the Animoog's special "keyboard" couldn't do the whole job, to get a better spooky Theremin howling sound I needed to add a little bit of a TalkBox effect and important to this thread, I had to rework the Theremin alike audio track using volume automation. If it would have been possible to use MIDI instead of an audio track, it would have been possible to move notes a little bit forward and backward instead of playing it again and again, but it still would have require to do some rework. Programming the used sound to use up and down movements of the finger to either do the desired howling or to allow volume control, would have been possible, but it would require to learn how to do it. I purchased a lot of proprietary virtual synth with a lot of features neither old fashioned digital, nor analog synth provide. Sometimes programming sounds using those new synth is easy to do, but often it has got a learning curve that IMO isn't worth the effort. IMO it's better to spend time to improve the skills to play a real instrument, this gains more to make good music, than learning how to program each gimmick, that doesn't gain as much as people guess. I like to get MIDI 2, but as pointed out by the QjackCtl GUI thread, it would be more important if virtual synth would care about e.g. MIDI 1 clock to sync delays, LFOs etc., something a lot of proprietary synth already do, but that is still completely missing for Linux. Host integration of virtual synth still needs to be improved especially for Linux FLOSS , but still for proprietary software for other OS, too. IOW I'm sceptic that MIDI 2 does solve much, since there are easy to use MIDI 1 features already ignored, such as using MIDI clock to sync LFOs of synthesizers. It's comparable to politicians sharpening laws, that are already sharp enough, but suffer from other issues such as bureaucracy or something else caused by reality. Sharpening a law that isn't/can't be used, doesn't solve an issue. Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Potential MIDI headaches?
On Sun, 20 Jan 2019 14:29:46 -0800 (PST), Len Ovens wrote: >I also wish I was 30 years younger with todays knowledge... In my opinion knowledge means less. More important IMO is the motivation, the skills to use free time. I wish I would be 30 years younger with the gear I own today. For example, Floyd Rose and active Humbuckers already existed when I was 30 years younger, but I didn't had the money to pay for it. I was young, highly motivated and a very good guitarist. Today I'm less motivated and as a consequence, in relation to back then, I'm a lousy guitarist today, but today I own this and other gear, some of what even didn't exist that time. For example, for some time the best synth "workstation" I owned was a Roland MT-32, fortunately with software to program it, but since it had only one MIDI in, data overflow that could cause a missing hi-hat now and then was a serious limitation. As for knowledge I could be 30 years younger, even without nowadays knowledge, since as a consequence of my highly motivation, I was very fast in learning. The issue today is motivation. I don't use my time as good as I was able to use it, when I was young. The young man was able to manage the time for women for a lot of friends for programming audio software for making music with a band for making music on his own to go to school or work The old man is unable to manage the time just for a few friends to make music on his own to go to school or work ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Potential MIDI headaches?
PS regarding robot pianos:
A workaround for one issue would be to select different velocity curves
by a CC message, to fit to different parts of a song played by a piano
master class. Software even could transmit measuring probe data from
the robot piano to the software via MIDI 1 to determine an appropriate
velocity curve. Even within the limits of MIDI 1 the problem with
robots is that robots need a completely different approach. A better
MIDI standard would improve the situation for robots, too, but never
ever does solve the robot problem.
--
pacman -Q linux{,-rt{-securityink,-cornflower,,-pussytoes}}|cut -d\ -f2
4.20.3.arch1-1
4.19.15_rt12-0
4.19.13_rt10-0
4.19.10_rt8-0
4.18.16_rt9-1
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Potential MIDI headaches?
On Sat, 19 Jan 2019 18:31:29 -0800 (PST), Len Ovens wrote:
>Being able to pitch change each note separately. Having many more CCs.
>Just to name a few. Guitar to MIDI can make good use of it.
I'm playing a Roland GR-55 guitar synth. It has got a MIDI input, but
it does not recognize note numbers. The rational for this might be
related to the way the synth is able to use the signals of the hex
pickup and that apart from the PCM tones, the patches could contain
modeling. Modeling doesn't just mean guitar and amp emulations, it's
also for modeling an analog synth. The MIDI output provides all MIDI
data, but that data can't compare to the data used by the synth. OTOH
the MIDI settings provide to turn chromatic output on and off, actually
it's turned off, but the output is chromatic, IOW I don't understand
this setting for the MIDI output. The chromatic switch for the PCM
tones is interesting. The tones are played in chromatic steps, even if a
string is bend, the pitch will change in semitones, when turned on. If
it's turned off, the PCM tones follow the real pitch of each string.
This is very cool, but hardly usable, since each noise a string does
produce has got impact, when turned off. Even the most accurate guitar
player can't avoid e.g. fret noise of new strings. IOW if the
sensitivity settings of the hex pickup are chosen to track nuances of
the guitarists playing, it requires to turn chromatic on, since if it's
turned off, it's nearly impossible to avoid unwanted notes. The current
generation of guitar synth does not allow practicable usage of all
provided abilities.
While MIDI 2 might be able to transmit the real data that is produced
when chromatic is turned off, it's not much usable and regarding
modeling MIDI anyway is the wrong interface.
To replace my keyboard by the guitar, MIDI 1 already does the job. At
the moment I play synth most of the times via a 12.9" touch screen,
usually just to produce regular MIDI 1 data. A touch screen could also
produce MIDI 1 incompatible data, but it's very seldom useful.
The MIDI we know has got several pitfalls and indeed some
improvements are very good, but all in all it already does everything a
musician does need. Yes, to control a mechanical monstrosity, such as a
robot piano MIDI isn't an adequate interface and I doubt that this
would change by a new MIDI standard.
A guitar synth does use the guitar as an input device, via a hex
pickup. It isn't a robot guitar, there are no stepper motors picking,
slapping, muting etc. the strings for playback.
It's not the MIDI standard that fails to play a robot piano, the
designers are idiots, if they use MIDI to control this kind of robot.
MIDI 2 could be useful for guitar synth, especially for guitar synth of
the next generation. A new MIDI standard could also be useful to get
rid of a few pitfalls, but it unlikely will become a robot interface.
--
pacman -Q linux{,-rt{-securityink,-cornflower,,-pussytoes}}|cut -d\ -f2
4.20.3.arch1-1
4.19.15_rt12-0
4.19.13_rt10-0
4.19.10_rt8-0
4.18.16_rt9-1
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Potential MIDI headaches?
On Sat, 19 Jan 2019 09:47:56 +, Will Godfrey wrote:
>I've just been told about this.
>https://www.midi.org/articles-old/the-midi-manufacturers-association-mma-and-the-association-of-music-electronics-industry-amei-announce-midi-2-0tm-prototyping?fbclid=IwAR3yojtbqXc52uTwrBV4uaUV7JdsMHMKIXA2NudhUH4mw8uPlmbxAPoDW3Q
>
>Looks like we might have quite a lot of work to do :/
"Backwards compatibility is a key requirement." -
https://www.midi.org/articles-old/midi-manufacturers-association-mma-adopts-midi-capability-inquiry-midi-ci-specification
So if your app works well with the current MIDI, you don't need to
migrate to MIDI 2.0.
--
pacman -Q linux{,-rt{-securityink,-cornflower,,-pussytoes}}|cut -d\ -f2
4.20.3.arch1-1
4.19.15_rt12-0
4.19.13_rt10-0
4.19.10_rt8-0
4.18.16_rt9-1
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Open Source Design (paid and pro bono design)
On Thu, 2018-11-29 at 18:02 +0100, Thorsten Wilms wrote: > On 29/11/2018 17.32, Louigi Verona wrote: > > Interesting that on their goals page they never mention "users" or > > "customers". So how are they going to understand what works if users are > > never consulted? > > That's clearly up to every single project. So from the point of view of > "Open Source Design", the question is what works or doesn't work > regarding designer involvement and designer-developer interaction. An issue advertising agencies know is the medium-sized business customer of the advertising agencies who already has got an idea. "My wife likes red pullovers and penguins. The logo for my power drill company should contain a penguin wearing a red pullover." The advertising agencies try to explain that the logo should represent the power drills and perhaps something else, maybe environmental sustainability or what ever is up to date, but there's no chance, if the wife of the customer likes red pullovers and penguins. At least the https://opensourcedesign.net job offers come with this issue, too, see https://design.blog.documentfoundation.org/2017/06/28/competition-libreoffice-mascot/, the mailing list already knows what they like and every Tom, Dick and Harry has some bikeshedding to contribute. Regarding software development the users' needs are important, regarding logo design the designers are the experts and nobody else. Big companies usually know this. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?
On Mon, 29 Oct 2018 15:34:44 +0100, Robin Gareus wrote: >Why? I've never seen someone installing/removing software while >recording or mixing. It also sounds like a bad idea to me. I agree that it is a bad idea, but decided yesterday not to reply to this thread and mention that it is a bad idea, because it could happen. This especially could happen, when using proprietary software, but not being rich, so the approach likely is to purchase software that time, when it's needed for the first time. In the days we used analog audio studios, it could happen that we left the studio, go by car to a music shop or friend, drove back and installed a new effect to the effect rack. There was no need to power off the gear. However, as long as it should be possible to save the state of a session done with computers, it should take less time to download and install new software and to restart the session or even to restart the computers, than to go by car to a music shop or friend and drive back. If possible I already would buy all the needed analog gear and install all the required software already before starting a recording session, but this strategy could suffer from not having the money to pay for everything that perhaps is needed, but not necessarily might be needed. As for free as in beer software the user should install everything that perhaps is needed, even if it shouldn't be necessarily needed, unfortunately not everything is for free as in beer. However, after a while we usually own all we need, so it doesn't happen that often in life. It's similar to a power outage. They already happened several times, but we usually can't remember when one happened the last time, but power outages do happen and it happens that a user needs to install new analog gear or new software during a session. ___ 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
On Sun, 2018-09-02 at 07:26 -0400, Paul Davis wrote: > On Sun, Sep 2, 2018 at 3:02 AM, Will J Godfrey > wrote: > > 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. > > a couple of days ago, while working on MIDI Clock support in ardour, i > was trying to figure out the origin of some missing Clock (0xf8) > messages. they would arrive every 830 samples plus or minus about 30 > samples,. but every once in a while, the gap would be twice that. > > long story cut short: just changing from using my MOTU Ultralite AVB > for MIDI I/O to a Midisport 2x2 fixed the problem. No more missing > Clock messages. > > could be relevant to stories like the one above. there's no good > reason for this, but it is how things are. Such an issue could be related to the used opto-coupler and diode or by a trim potentiometer for sensitivity that isn't set up properly. I adjusted the trim potentiometer of my DIY MIDI throu box build in the 80s to work with old gear, but nowadays USB devices not always provide enough current to drive the MIDI throu box with this adjustment. I heard of issues related of slow opto-couplers or diodes to fix slope issues, but never experienced this myself. ___ 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
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. ___ 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
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) That is incorrect, MIDI was designed for sequencer usage, too, so MIDI provides 16 channels ;). While I only can play 6 channels in real-time using my guitar synth, even my C64 and Atari ST could play 16 channels and more (btw. with way less MIDI jitter than any Linux PC can do). Depending on the usage, we can _not_ use one MIDI connection (one MIDI cable) for all 16 channels, but sometimes it works, let alone that from the beginning MIDI also was desgined for usage with several MIDI IOs, IOW for usage with x * 16 channels. Btw. regarding some data, e.g. pitch bend messages, not only my guitar synth allows to send "reduced" MIDI data. From keyboards we e.g. know that after touch often isn't used, but send. MIDI sometimes require thinking about the setup, to avoid issues, this is even true for an anlog audio setup or synth connected by a CV/gate "network". MIDI still requires to think about what we want to achieve. The MIDI standard isn't made to fit the needs of braindead consumers. If we think a little bit, we even could use SysEx non-real-time MIDI data in real-time, without experiencing any problem. ___ 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
On Sat, 01 Sep 2018 16:49:48 -0500, Jonathan E. Brickman wrote: >to sidestep all of the well-known MIDI limitations Without doubts MIDI has got well-known limitations, but nowadays a bad implementation of the MIDI standard often gets confused with the MIDI standard, so it's better to clearly point out a limitation instead of overgeneralizeing the issues. ___ 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
[Active Sensing] You said that you "need lossless JACK MIDI networking", but not why you need networking at all. You might have a good reason, I'm just curious. For what purpose do you need an _additional_ network? Btw. I have no experiences with MIDI over an additional network, but regarding the missing note-off issue, a standard MIDI "network" (= MIDI not over an additional network) has got the "Active Sense" (0xFE) message, that could workaround some (not all) missing note-off issues. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] jackd not using jackdrc...
PS: On Fri, 3 Aug 2018 10:46:02 +0200, Ralf Mardorf wrote: >Even a clueless Arch Linux user could _not_ come in the position to >wonder, if a jack package might be missing, since jack1, as well as >jack2 are each provided by a single package and no virtual package is >required either. There's one exception were an Arch jack package is split. Jack2 is split to jack2 and jack2-dbus. >IIRC in the past there indeed were symlink issues, since the >Debian and/or Ubuntu maintainers didn't split the packages correctly ...or at least they didn't link correctly. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] jackd not using jackdrc...
On Fri, 3 Aug 2018 09:49:15 +0200, Fokke de Jong wrote: >google told me someone with the same problem solved it by installing >either libjack-jackd2-dev or libjack-dev. in installed libjack-dev, >but it didn’t help so i removed it again. The '/usr/lib/x86_64-linux-gnu/libjack*so' symlinks against '/usr/lib/x86_64-linux-gnu/libjack*so*', as well as the header files provided by https://packages.ubuntu.com/artful/amd64/libjack-jackd2-dev/filelist (jack2) are required to build apps, they are not required at runtime. The additional *.a files provided by https://packages.ubuntu.com/artful/amd64/libjack-dev/filelist (jack1) are also not required at runtime. Without the 'dev'elopment packages you can't build apps that should use jack. Once you build such apps, you could remove those packages. That Debian and Ubuntu split jack packages https://tracker.debian.org/pkg/jackd2 https://tracker.debian.org/pkg/jack-audio-connection-kit and that to workaround the jack1/jack2 'issue' the virtual 'jack' package is required, not necessarily could be considered a 'user-friendly' policy and package management. Arch Linux has got a different policy and another package management. Even a clueless Arch Linux user could _not_ come in the position to wonder, if a jack package might be missing, since jack1, as well as jack2 are each provided by a single package and no virtual package is required either. IIRC in the past there indeed were symlink issues, since the Debian and/or Ubuntu maintainers didn't split the packages correctly. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Fwd: ( Custom Arch Linux or Custom Ubuntu Studio ) for ( Proffesional Audio & Game Audio Development )
I've forgotten to mention that On Sun, 1 Jul 2018 20:16:07 +0200, Ralf Mardorf wrote: >You could install Ubuntu from the server image and after that install ubuntu-studio meta-packages, see https://packages.ubuntu.com/search?suite=bionic=all=any=ubuntustudio=names FWIW I prefer Arch Linux over Ubuntu flavours such as Ubuntu Studio. I stay away from derivatives with small communities, less developers and sometimes even without mailing lists or any support at all. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Polyphonic normal guitar to midi: Jam Origins' MIDI-Guitar
PPS:
On Sat, 30 Jun 2018 09:55:41 +0200, Ralf Mardorf wrote:
>You neither described why it didn't work
If you don't know the reason, you at least could mention that you build
something this or by another way and that you run it this or that way,
without getting any messages.
--
pacman -Q linux{,-rt{,-securityink,-cornflower,-pussytoes}}|cut -d\ -f2
4.17.3-1
4.16.15_rt7-1
4.16.12_rt5-1
4.16.8_rt3-1
4.14.34_rt27-1
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Polyphonic normal guitar to midi: Jam Origins' MIDI-Guitar
On Sat, 30 Jun 2018 09:49:48 +0200, Ralf Mardorf wrote: >To get something working that didn't work in the first place, while it >likely should work in the first place, you "hack"ed it in a way that it >still doesn't work. PS: You neither described why it didn't work, nor what "hack"s you are using, that it still doesn't work. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Polyphonic normal guitar to midi: Jam Origins' MIDI-Guitar
Hi, I'm not really able to help you with this specific SC issue, however, you should describe the issues you experienced more detailed. An/the SC package of what Suse release is broken? In what way the package is broken? Just imagine usage of a third party repository and e.g. a soname issues. To get something working that didn't work in the first place, while it likely should work in the first place, you "hack"ed it in a way that it still doesn't work. I guess it's self-explaining that you can't expect much help to solve this issue, by providing entirely ambiguous information. Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Polyphonic normal guitar to midi: Jam Origins' MIDI-Guitar
On Tue, 26 Jun 2018 15:03:04 -0400, Tim wrote: >If I understand correctly the theory goes something like this: >If you are looking for a dog in a picture, far better to compare > with real pictures of dogs already stored than to only have > a rough mathematical idea of what a dog should look like. Yes, they seemingly solved one issue of several issues. What happens when playing the following chord A7#9 e a d g b e 6 | | | o | | 7 | | o | | | 8 | | | | o o and while holding the chord bending the b and e string at the 8th fret? Keep in mind that using a divided pickup it's possible to e.g. use modeling for the e, a and d string, e.g. a neck pickup of a Stratocaster, with a Drop D tuning (while the guitar is a LesPaul not tuned to a Drop D tuning), while the g, b and e string send MIDI messages to 3 different MIDI channels. >There is talk of this software obsoleting using special pickups. >I would tend to agree, it's pretty darn good. Perhaps if the purpose is sending MIDI events only, but a guitar synth provides more. You individually could change the volume and tuning of each strings output, you could change the velocity curve. Some sounds such as a lead synth allow pitch bend, while bending a guitar string, other sounds, such as a grand piano don't allow this. In addition you could mix it with all kinds of modeling. >> My new guitar additionally has got a Sustaniac driver. > >Ah, just looked that up. >Similar to the famous e-bow hand-held sustainer? Yes, but it could add endless sustain to a note and by a three position switch fade to 2 different kinds of harmonics to simulate feedback. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Polyphonic normal guitar to midi: Jam Origins' MIDI-Guitar
On Mon, 25 Jun 2018 18:31:12 -0400, Tim wrote: >Then I stumbled across this product, MIDI-Guitar from Jam Origins. For quite some time now, the free version is installed on my iPad, but I never tested it and meanwhile I've got two electric guitars with Roland GK-3 PUs and a Roland GR-55. Keep in mind that even the best polyphonic tracking done by software for Apple and Microsoft based computers, for usage with averaged guitar pickups, at least suffers from the additional audio device latency. Before I bought the Roland gear, I watched videos and read reviews. Roland seems to be the best solution at the moment, even combinations of a Roland GR-55 with piezo bridge pickups, instead of the Roland GK-3 seems to be less reliable. However, for several reasons it indeed would be nice, if the polyphonic tracking software, for usage with averaged guitar pickups would make progress. OTOH some kind of divided pickup build into modern guitars has got an advantage, too, since modeling makes a lot of progress. My new guitar additionally has got a Sustaniac driver. IOW adding special pickups to guitars is not necessarily a disadvantage. Perhaps polyphonic tracking software, for usage with averaged guitar pickups, in combination with special pickups is interesting in the near future. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] rosegarden doesn't use system qt5 font
On Mon, 12 Mar 2018 00:04:31 +0500, Nikita Zlobin wrote: >For qt5 config i use qt5ct. Oops ;), I missed that :D. Yes, it's a PITA :). ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] rosegarden doesn't use system qt5 font
Take a look at https://wiki.archlinux.org/index.php/qt one way is using the plugin [1], that not necessarily does a good job, but, hey, that is nowadays Linux, it's absolutely inconsistent. [1] No Rosegarden here, but Rui's apps are based upon Qt, too: [rocketmouse@archlinux ~]$ qjackctl qt5ct: using qt5ct plugin ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ome news and Linux Audio Programmer job position at MOD Devices
>On Sat, 10 Mar 2018 11:38:21 -0600, Jordan Halase wrote: >>Ralf, we aren't living under a rock. That's been everywhere. Sure, >>"greetings gentlemen" is an innocent error, but there is no need to >>stretch this out any further. >> >>Please stop. > >Actually, it wasn't me who pushed this ;). Vice versa, I didn't care at >all about the original issue. > >See > >https://lists.linuxaudio.org/archives/linux-audio-dev/2018-March/037083.html The above is the wrong link, here is the correct link: https://lists.linuxaudio.org/archives/linux-audio-dev/2018-March/037077.html > >continued by > >https://lists.linuxaudio.org/archives/linux-audio-dev/2018-March/037083.html > >Don't worry, as from now I will ignore this thread. ___ 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
On Sat, 10 Mar 2018 11:38:21 -0600, Jordan Halase wrote: >Ralf, we aren't living under a rock. That's been everywhere. Sure, >"greetings gentlemen" is an innocent error, but there is no need to >stretch this out any further. > >Please stop. Actually, it wasn't me who pushed this ;). Vice versa, I didn't care at all about the original issue. See https://lists.linuxaudio.org/archives/linux-audio-dev/2018-March/037083.html continued by https://lists.linuxaudio.org/archives/linux-audio-dev/2018-March/037083.html Don't worry, as from now I will ignore this thread. ___ 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
PS: "[off-list] [LAD] Some news and Linux Audio Programmer job position at MOD Devices" Oops, it was intentioned to sent it to the list, I just forgot to remove the [off-list] in the subject. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] [off-list] Some news and Linux Audio Programmer job position at MOD Devices
On Sat, 10 Mar 2018 10:53:42 -0600, Jordan Halase wrote: >I'd suggest keeping any and all political discussion out of open >source completely. Learn from the other open source communities who >let it eat them alive. You are right! However, there were a lot of heated-up debates regarding the new CoC of FreeBSD. https://www.freebsd.org/internal/code-of-conduct.html The reason for those heated-up debates is the wish to keep politics out of the FreeBSD community, e.g. by reverting to the old CoC, that covers all this by not explecitely mentioning it, since gender politics anyway never was an issue on any open source community. ;) IMO it is self-explanatory that "Greetings gentlemen" is a formatting error, without the intention to exclude anybody else. ___ 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
On Fri, 9 Mar 2018 19:51:58 +0100, Cedric Roux wrote: >On 03/09/2018 07:26 AM, Ralf Mardorf wrote: >> Be carefull with this, you might offend Geek Feminism views by your >> best wishes, maybe Women's Day is a white men's invention to harass >> people's gender identity and expression and sexual orientation. > >Please, behave. And read some history. Thank you. >https://en.wikipedia.org/wiki/International_Women%27s_Day Hi, please get involved. Some of us are involved in gender politics since decades. Nowadays there are radical associations damaging the success gained by decades of hard peaceful work done by other. Your Wiki link doesn't mention Geek Feminism, maybe because alt-right insults against those who worked on equality since decades usually comes from Geek Feminism and similar radical folks. See http://geekfeminism.wikia.com/wiki/Nonsexist_language . Are you speaking German? The German language can't be used by taking care about this nonsense. The English term "referee" in German is split into "Schiedsrichter" (male) and "Schiedsrichterin" (female), so if the World Trade Organization should become "Schiedsrichterin" in a possible comming economic war, nobody in Germany is offended, nobody does think it will suppress men. " Women as Afterthought "Hello gentlemen ... and lady." This tends to convey the message that gentlemen are the intended audience, and highlights the woman in the room in a way which at best feels awkward, but can become threatening if the audience targets the woman for unwelcome attention." - http://geekfeminism.wikia.com/wiki/Nonsexist_language *?* Good night! Ralf ___ 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
On Thu, 8 Mar 2018 22:56:10 +1100, David wrote:
>On 8 March 2018 at 19:51, Gianfranco Ceccolini
>Greetings Developers!
>
>Happy International Women's Day to everyone!
Be carefull with this, you might offend Geek Feminism views by your
best wishes, maybe Women's Day is a white men's invention to harass
people's gender identity and expression and sexual orientation.
Related links:
https://www.freebsd.org/internal/code-of-conduct.html
https://ixquick-proxy.com/do/spg/show_picture.pl?l=english=1=https%3A%2F%2Fi.ytimg.com%2Fvi%2F-4MJm6MM8W8%2Fmaxresdefault.jpg=8d7a534b496ef1f5d77206bdc4f1071e
--
pacman -Q linux{,-rt{,-securityink,-pussytoes,-cornflower}}|cut -d\ -f2
4.15.7-1
4.14.24_rt19-1
4.14.20_rt17-1
4.14.8_rt9-2
4.11.12_rt16-1
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] https for linuxaudio.org
On Sun, 10 Dec 2017 21:52:30 +0100, David Runge wrote: >You rule! >Thanks +1 But please, developers consider to sign your tarballs. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Carla (was... whatever)
On Sun, 10 Dec 2017 11:25:26 +0100, Ralf Mardorf wrote: >Off-topic: > >On Sun, 10 Dec 2017 10:51:43 +0100, Filipe Coelho wrote: >>In case you did not notice from me and Rui, we Portuguese people like >>to support as much stuff as possible :) > >Not really. For example, record a few audio tracks with Qtractor using >a low frame size, while you mute several tracks to avoid xruns. Then >for mixing purpose increase the frame size and enable all tracks. Oops, >the already not that good latency compensation, gets a little bit more >out of sync, in relation to the MIDI tracks ;). Do you claim that Portuguese people prefer quantity rather than quality over quality rather than quantity? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Carla (was... whatever)
Off-topic: On Sun, 10 Dec 2017 10:51:43 +0100, Filipe Coelho wrote: >In case you did not notice from me and Rui, we Portuguese people like >to support as much stuff as possible :) Not really. For example, record a few audio tracks with Qtractor using a low frame size, while you mute several tracks to avoid xruns. Then for mixing purpose increase the frame size and enable all tracks. Oops, the already not that good latency compensation, gets a little bit more out of sync, in relation to the MIDI tracks ;). ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Carla (was... whatever)
On Sun, 10 Dec 2017 09:33:25 +0100, Filipe Coelho wrote: >On 10.12.2017 00:21, Ralf Mardorf wrote: >> On Sat, 9 Dec 2017 18:00:32 +0100, Filipe Coelho wrote: >>> But when installing jalv or qtractor for archlinux, because they >>> depend on suil, expect it to pull gtk2, gtk3, qt4 and qt5. >> suil comes with a dedicated version itself and as far as I notice >> doesn't require ntk-git or even qt4 and qt5 at the same time, even >> not by it's one and only hard dependency lv2, let alone that even >> qt4 is an optional dependency. Following the dependency chain ... I >> might be mistaken .. even GTK3 seems not to be a hard dependency. >> Did I miss something by suil's dependency chain? > >You're missing the fact that all of these are optional dependencies. >Nothing in carla is a real build-time dependency. > >But obviously, if you want to load gtk2 uis on carla, you need gtk2. >Same goes for qt4, qt5 and gtk3. There is no way around this, you need >the toolkit during build-time in order to support it. > >ntk-git (and also fftw3, mxml and zlib) are dependencies of >zynaddsubfx. you can take those out if you don't care about zyn inside >carla. Please don't get me wrong, sometimes a plugin's GUI could be an advantage, but it also could be annoying. IMO plugins more often could be more comfortable, with an UI provided by the host. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Carla (was... whatever)
On Sat, 9 Dec 2017 18:00:32 +0100, Filipe Coelho wrote: >But when installing jalv or qtractor for archlinux, because they >depend on suil, expect it to pull gtk2, gtk3, qt4 and qt5. suil comes with a dedicated version itself and as far as I notice doesn't require ntk-git or even qt4 and qt5 at the same time, even not by it's one and only hard dependency lv2, let alone that even qt4 is an optional dependency. Following the dependency chain ... I might be mistaken .. even GTK3 seems not to be a hard dependency. Did I miss something by suil's dependency chain? ___ 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.
On Sat, 9 Dec 2017 09:44:02 -0500, Paul Davis wrote: >As a plugin host, Carla attempts (and generally does) allow plugins >to use many different toolkits for their own GUIs. Do you think that Fons is an idiot, not being aware of this? The issue still remains, the more dedicated dependencies, the more possible issues. However, let's ignore the GUI issue, for what purpose are fluidsynth and linuxsampler dependencies of a host? Especially linuxsampler is a serious issue for a lot of distros, regarding the customized/invalid license. Actually the official Arch Linux community repository provides linuxsampler, but you unlikely could mention much more major distros supporting it by their official repositories. Keep in mind that some distro's, such as Arch Linux follow the KISS principle, IOW an app usually is build with the upstream defaults, without excluding features. This at least could become tricky, as soon as e.g. a dependency to Steinberg is involved. Maybe not regarding the distro's policy, but at least regarding hunting for the current Steinberg download link. ___ 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.
On Tue, 5 Dec 2017 17:21:05 +0100, Louigi Verona wrote: >Microsoft and Apple are not the only examples of proprietary software, >sir. And proprietary software developer is not necessarily a >"corporation". At least the software that runs on e.g. an Apple operating system could be from developers who are not associated with Apple. >I have reacted to the initial post because a person was claiming that >because *a problem* on a Mac happened - that means that everything >which is a Mac is now a problem. I have responded that this does not >sound very reasonable and that I can talk about *a problem* I had with >Linux and apply the same logic. > >I think this rebuke was appropriate. Making sweeping generalizations >about all Macs or about all proprietary software (or about floss, for >that matter) based on isolated incidents is not an approach that will >deliver an objective overview of the situation in the world of >software. I'm using real-time audio software for iOS from a developer who tries to provide the same software for non-Apple tablet PCs, too, actually the only tablet PC platform that is suitable for professional audio usage is iOS. There is no such Linux based tablet PC platform available. Linux for our domain covers a very small market share. However, apart from this hardware related issue, a large amount of audio software isn't available for Linux. Good synth emulations are a proprietary domain of vendors who usually don't provide their software for Linux at all. Within the pro-audio domain there are sub-domains were comparison between Linux FLOSS and what ever kind of software for proprietary operating systems (also FLOSS or expensive closed source software) can't be compared, because for Linux a lot of software isn't available. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] https for linuxaudio.org
On Sun, 26 Nov 2017 18:10:15 +0100, Ralf Mardorf wrote: >[rocketmouse@archlinux ~]$ grep hkp luamd64_1610.sh >key gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys FBB75451 >EFE21092 I win praise for a script that downloads Ubuntu desktop flavours and does all the signed key procedure, but it was criticized that I used the key short ID. https://lists.ubuntu.com/archives/lubuntu-users/2017-November/011741.html https://lists.ubuntu.com/archives/lubuntu-users/2017-November/011747.html Tricky ;). ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] https for linuxaudio.org
On Sun, 26 Nov 2017 16:57:12 +, Fons Adriaensen wrote:
>- which keyserver to use ?
In cases of doubt simply use keys.gnupg.net ;).
To get a key by alias or by scripts I'm using different key servers e.g. [1].
Aren't the servers synced? I guess it's just useful that "Some famous LAD
members sign" your key, not which server you use to upload your key.
[1]
[rocketmouse@archlinux ~]$ grep hkp .bashrc
alias gkey='gpg --keyserver hkp://pgp.uni-mainz.de --recv-keys'
alias gkey2='gpg2 --keyserver hkp://keys.gnupg.net --recv-keys'
[rocketmouse@archlinux ~]$ grep hkp luamd64_1610.sh
key gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys FBB75451 EFE21092
--
$ pacman -Q linux{,-rt{,-cornflower,-pussytoes}}|awk '{print $2}'
4.14-2
4.13.13_rt5-1
4.11.12_rt16-1
4.14_rt1-1
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] https for linuxaudio.org
On Sun, 26 Nov 2017 16:51:53 +0100, David Runge wrote:
>> Not that much, since even when additionally using TOR, privacy isn't
>> ensured without exceptions,
>> https://www.torproject.org/docs/faq.html.en#AttacksOnOnionRouting .
>That of course is also true and thanks for pointing it out.
>When writing, I was more thinking of subdomains hosting applications,
>that require authentication (then seeing, that e.g.
>{lists,wiki}.linuxaudio.org already facilitate letsencrypt certs).
>
>Of course, given the right tools and infrastructure, it gets
>increasingly harder to achieve some form of privacy.
>However, that's no reason not to aim for the maximum amount thereof.
>
>In any case (unless your ssl is broken) and however one wants to turn
>it: It is beneficial to implement https and I'm happy to hear it will
>be done.
Btw. when I asked to provide Ardour for Arch with disabling the phone
home option, as Debian and Ubuntu already did, it was not because I had
concerns regarding upstream, I've done this, e.g. because activists use
Ardour and at the same time TOR browser, without redirecting all
traffic trough the onion. I'm pro ever little step to grant more
privacy by default, https is one of those steps. Actually ssl is much
known to the masses for Heartbleed, not for security and it's
kinda always in a broken state.
[rocketmouse@archlinux ~]$ arch-audit | grep ssl
Package openssl-1.0 is affected by CVE-2017-3736, CVE-2017-3735. Medium risk!
Ok, no output for openssl yet, just for openssl-1.0, however taking a
look at...
[rocketmouse@archlinux ~]$ pactree -r openssl-1.0
[snip]
[rocketmouse@archlinux ~]$ pactree -r openssl
[snip]
...we should take in consideration that ssl isn't the universal
salvation.
But again, I agree with you, https is better than no https ;).
Regards,
Ralf
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] https for linuxaudio.org
On Tue, 21 Nov 2017 10:27:26 +0100, Louigi Verona wrote: >Yeah, more security and privacy, because Linux Audio packages are >constantly attacked by enemies :D Btw. packages of major distros are signed. It would make much more sense, if upstream already would sign the tarballs providing the source code, too. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] https for linuxaudio.org
On Tue, 21 Nov 2017 11:39:49 +0100, IOhannes m zmoelnig wrote: >there is practically no reason to *not* use https:// everywhere It quasi became a standard, most websites I visit are https nowadays. We shouldn't overvalue https. I agree that it should be used, if it shouldn't be too much effort to migrate, but again, upstream should get used to provide signed checksums. On Tue, 21 Nov 2017 10:27:26 +0100, Louigi Verona wrote: >Yeah, more security and privacy, because Linux Audio packages are >constantly attacked by enemies :D I don't care much about privacy when visiting Linux audio related websites, but you shouldn't carelessly joke around regarding security. The Jack website was successfully hacked, IIRC more than once. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] https for linuxaudio.org
On Tue, 21 Nov 2017 02:54:14 +0100, David Runge wrote:
>Would it be possible to implement letsencrypt for linuxaudio.org and
>all of its subdomains?
>This would greatly improve the security of the packages hosted there
>(or rather their transfer from the server to the build machine) and
>help for said packages not to be dropped, as more and more distros try
>to switch to more reliable and authenticatable (is that a word?)
>upstreams.
Hi,
for security reasons developers should consider to provide signed
checksums, as fortunately e.g.
https://www.kernel.org/category/signatures.html does. This was
discussed at e.g. Arch general.
>Additionally, there is the benefit of raising privacy for users of all
>things hosted on linuxaudio.org.
Not that much, since even when additionally using TOR, privacy isn't
ensured without exceptions,
https://www.torproject.org/docs/faq.html.en#AttacksOnOnionRouting .
Regards,
Ralf
--
$ pacman -Q linux{,-rt{,-cornflower,-pussytoes}}|awk '{print $2}'
4.14-2
4.13.13_rt5-1
4.11.12_rt16-1
4.14_rt1-1
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] sourceforge - update
In the meantime I unsubscribed from the new alsa-user account. It's possible to send mails to the list using the old account and receiving mails from the list works, too. I'm still not subscribed to alsa-devel, but receive the alsa-devel digest :D. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] USB audio interface
PS: You mentioned live usage. If you use a 19" rack it doesn't matter, if you chose a Presonus AudioBox 1818VSL or a Focusrite Scarlett 18i20 2nd Gen, but if you carry the device in a bag, it might be important, to be aware that the Presonus is smaller, but it has got an external power supply. The power supply is also small. However, the Presonus requires more power via USB, than the Focusrite, it's within the standard, but some portable computers might need an USB hub, if they should limit USB power to safe energy. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] USB audio interface
Hi, in December 2016 I bought a B-Stock Presonus AudioBox 1818VSL for 309.00 €, but I send it back, because it didn't work with iOS. It works with Linux. In January 2017 I bought a brand new Focusrite Scarlett 18i20 2nd Gen for 382.00 €. It works with Linux as well as with iOS and allows lower latency than the Presonus. Neither the headphone amp of the Presonus, nor the one of the Focusrite could compare to my PCIe RME card, but sound quality of all IOs is as expected for pro-sumer devices. You won't get a professional audio device for <= 500.00 €. My recommendation is the Focusrite. Behringer devices are less expensive, but since reviews mentioned power supply issues, I wouldn't buy one, even if they should sound good and if they should work with Linux OOTB. With other Behringer gear I experienced power supply issues myself. Consider to buy a Focusrite, test it and return it if you aren't satisfied [1]. If you could wait, you might get a special offer for less than 400.00 €, too, the regular price is > 450.00 € at the moment. For that price range the Focusrite IMO is a good choice. If you could spend more money, a Babyface with an ADAT device much likely is a better choice. FWIW I've got an ADAT device, the Focusrite could be extended by ADAT and S/PDIF, so if you use both, you get 18 inputs and 20 outputs. https://d2zjg0qo565n2.cloudfront.net/sites/default/files/focusrite/downloads/31605/scarlett-18i20-2nd-gen-user-guide.pdf It's perhaps better to send such a request to Linux Audio User, than to Linux Audio Dev. Regards, Ralf [1] It doesn't make sense to say more about the Focusrite, since you never know if all devices work in the same way. It's said that the Presonus should work with iOS, but for me it doesn't. It's said that my RME card should work with Linux, but it does cause issues, IOW not everything works. So if I would spend time to write more about the Focusrite, it might not be helpful, since it might be different, if you use the device. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Linux Support for Focusrite Scarlett 18i20 2nd Generation
On Wed, 2017-06-21 at 12:47 -0700, Lloyd Dickman wrote: > I am trying to make a Focusrite Scarlett 18i20 (2nd Generation) work > as a USB audio capture device with Linux. Hi, last time I used my Focusrite Scarlett 18i20 (2nd Generation) with Linux all digital and analog outs worked without issues. I don't remember if all inputs work as well. IIRC all inputs also did their job, however, I need to check this, but at the moment I have got no time to do so. On Wed, 2017-06-21 at 22:06 +0200, Peter wrote: > I actually configured nothing, it just worked (using 44.1 and 48 kHz). > Still, it's annoying that the higher sampling rates do not work, > and access to the mixer would also be nice. I didn't test useless sample rates, so I don't know if other sample rates work as well. The mixer doesn't work, since it's used in class compliant mode. We know this before we buy the device, so actually I don't need the mixer. For hardware monitoring I would use a mixing console, let alone that latency is very low, so even software monitoring might be possible. The only drawback of the Focusrite IMO is the sound quality. It can't compare to professional audio devices, OTOH my RME card was much more expensive by providing less IOs, let alone that my RME HDSPe AIO doesn't work correctly with Linux, e.g. just 2 ADAT channels are accessible by jackd and the latency is not very good. Ardour can't access the RME card without jackd at all, so I must use jackd. Résumé: If the Focusrite doesn't work, much likely something is fishy with your Linux setup and/or the Focusrite. However, I never touched the mixer settings, I'm using it with the default mixer settings, less often with Linux, more often with iOS and usually I'm using the ADAT outputs and one of the weak lofi headphone outputs only. Regards, Ralf -- Vote for apulse! echo $(w3m https://aur.archlinux.org/packages/apulse |grep 'Votes:') Votes: 70 Updated: Thu Jun 22 05:45:41 CEST 2017 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Failed to connect to session bus for device reservation
On Wed, 15 Feb 2017 07:45:49 -0800 (PST), Len Ovens wrote: >One of the biggest problems in linux audio is old information, linux >and the surrounding OS has changed. The biggest issue within this problem are wikis with links. When maintaining a Wiki, with too many links, nobody will check the content of all links, so we tend to not remove the work of others, because a link might be useful. Usually we only remove dead links, but not bad links. IMO the best approach is, wenn editing a Wiki, to avoid adding links, whenever possible. Another issue is self-responsibility. If a good documentation e.g. mentions /sys/bus/pci/drivers/ohci_hcd/unbind to unbind USB devices that share an IRQ with an audio interface, it shouldn't be that hard, to find out that the location changed to /sys/bus/pci/drivers/ohci-pci/unbind A problem could be to notice this or similar issues. At least I don't check such things all the times when making music. However, it's wise to not upgrade during a production, so there's no need to check everything. IOW when making music, it's not wise to upgrade Ardour, Guitarix etc., let alone to upgrade the kernel or something security related. I even wouldn't risk an openssl heartbleed alike fix, something absolutely necessarily for a lot of tasks, but completely irrelevant for a DAW. Btw. I'm a jack2, but jackd and not jackdbus user. Never change a winning team! Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] aBLETON lINK
On Fri, 23 Sep 2016 13:00:08 +0200, Patrick Shirkey wrote: >> On Thu, 2016-09-22 at 19:58 +0200, Robin Gareus wrote: >>> That's pretty cool IMHO and I wish more companies would do that! >>> >>> 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. >> >> The whole point of such a protocol as they've developed it is to >> increase creativity and to open up possibilities for collaboration >> and new musical ideas. Isn't that one of the reasons we like to >> hangout on mailing lists like this one? > >Some us us disagree that this IS the "whole point" of Link. >From my user point of view I welcome Linux apps integrating Ableton Link. Actually I don't know if I really need it, but it doesn't harm to have the opportunity to use it. Some subscribers explained that it's not just another way to sync by one master and several slaves. I've got a question. If I e.g. have one device at 180 BPM and another at 90 BPM, they both could keep the their own tempo and would play in sync? This double/half speed thing is a common MIDI sync issue. Regards, Ralf ___ 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, 20 Sep 2016 07:03:58 +0200, Patrick Shirkey wrote: >Because netjack isn't good enough or cross platform enough or LGPL >enough or adopted enough? Hi, yes, it's not cross platform enough. Audiobus and other iPad apps provide Ableton Link. Jack doesn't run on the iPad anymore, so there unlikely ever will be netjack available. It would be nice to be able to sync a tablet PC with the Linux DAW by wifi. AFAIK Linux based tablet PCs are still not real-time capable. I have no idea how good sync by wifi works, maybe MIDI by cable still is the better way to go. Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Multiple JACK servers connected in one host?
>Indeed -- except that cars in Manhattan are restricted to using wheels >:-) I have rocket engines which don't give off exhaust at all, lots >and lots of fuel, no skyscrapers in the way, and no one else in the >air; I am going to either learn or help build a way to use those >engines :-) The analogy shouldn't be that the computer is a Formular-1 car or a rocket, the analogy should be that jack is a courier and the streets are the software and the computer. I still suspect that jack2 is (are) several bike couriers, wich nowadays seem to be the best solution in big cities, resp. nowadays soft- and hardware. However, in the future couriers might prefer "Back to the Future" hoverboards. A hoverboard ollie (skateboarding trick where the rider and board leap into the air without the use of the rider's hands) would allow to exploit additional transport infrastructure. IOW the next generation hardware might ask for jack3. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Multiple JACK servers connected in one host?
>On 03/11/2016 02:24 PM, Patrick Shirkey wrote: >> According to Jonathan his multiple cores are barely reaching 5% >> usage. How can JACK_DSP be so high when there is so much room left >> to play with if JACK2 is handling the parallelism correctly? >> >> It seems similar to my car telling me that I am red lighting when I >> am only going 20km/hr in second. > >The proper analogy here would be a Formula-1 car in Downtown Manhattan >during rush hour :) Or perhaps Jack2 already 'are' the bike couriers in Downtown Manhattan during rush hour. Jet pack couriers or a trail bike couriers would be faster than the bike courier, but also more prone to accidents. Perhaps the OP is asking for bike couriers, who when ever it is possible temporarily use a jet pack. OTOH carrying a jet pack on the back, would slow down riding the bike. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] No sound after login
On Wed, 2 Mar 2016 16:53:07 -0800 (PST), Len Ovens wrote: >KDE uses XDG Hi, were autostart is located depends on the environment and on the used distro. For my Ubuntu Wily install I needed to clear XDG_CONFIG_DIRS at top of my openbox autostart config, to get rid of unwanted autostarts. I don't need to do this for my Arch Linux install. [weremouse@moonstudio ~]$ grep XDG .config/openbox/autostart export XDG_CONFIG_DIRS="" [weremouse@moonstudio ~]$ grep XDG /mnt/archlinux/home/rocketmouse/.config/openbox/autostart [weremouse@moonstudio ~]$ At least /etc/xdg/autostart/ is active by default for Ubuntu flavours and Ubuntu derivatives, what ever WM/DE you're using. Instead of ~/.profile, I would use ~/.bashrc. Usually bash is the login shell, so a ~/.bashrc is available. Instead of using two locations, ~/.profile and ~/.bashrc, I would edit just one location, ~/.bashrc. [weremouse@moonstudio ~]$ grep -v "#" .profile if [ -n "$BASH_VERSION" ]; then if [ -f "$HOME/.bashrc" ]; then . "$HOME/.bashrc" fi fi if [ -d "$HOME/bin" ] ; then PATH="$HOME/bin:$PATH" fi [weremouse@moonstudio ~]$ ls -hAl /mnt/archlinux/home/rocketmouse/.profile ls: cannot access /mnt/archlinux/home/rocketmouse/.profile: No such file or directory For Gene's purpose /etc/rc.local is asking for a race condition, it seems to be better to run the command while starting a session and not during startup. IMO /etc/xdg/autostart/ is the appropriate location for Gene's purpose. Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] cpu spikes
On Mon, 8 Feb 2016 11:14:45 +, Harry van Haaren wrote: >I think it would be great if the Linux Audio community built up a list >of kernel config options that need changing for optimal audio >performance. Indeed, the rt config became tricky a while ago, especially for AMD based machines. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] cpu spikes
On Mon, 8 Feb 2016 21:31:08 +0100, Jeremy Jongepier wrote: >On 02/08/2016 08:11 PM, Ralf Mardorf wrote: >> I forgot to mention, the lowlatency is a vanilla kernel with a >> special configuration, but without a realtime related patch. > >Afaik the Ubuntu low-latency kernel doesn't really have a special >config, just CONFIG_PREEMPT and CONFIG_HZ_1000. A comparison between a standard Arch and an Ubuntu lowlatency kernel of a few other things that come to mind on the fly: [rocketmouse@archlinux ~]$ uname -r 4.4.1-2-ARCH [rocketmouse@archlinux ~]$ zgrep THREADING_DEFAULT /proc/config.gz [rocketmouse@archlinux ~]$ grep THREADING_DEFAULT /mnt/moonstudio/boot/config-4.2.0-27-lowlatency CONFIG_IRQ_FORCED_THREADING_DEFAULT=y [rocketmouse@archlinux ~]$ zgrep Q_DEFAULT_GOV /proc/config.gz # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set [rocketmouse@archlinux ~]$ grep -i Q_DEFAULT_GOV /mnt/moonstudio/boot/config-4.2.0-27-lowlatency CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set [rocketmouse@archlinux ~]$ zgrep NO_HZ /proc/config.gz CONFIG_NO_HZ_COMMON=y CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set # CONFIG_NO_HZ is not set [rocketmouse@archlinux ~]$ grep NO_HZ /mnt/moonstudio/boot/config-4.2.0-27-lowlatency CONFIG_NO_HZ_COMMON=y CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] cpu spikes
On Mon, 8 Feb 2016 19:44:49 +0100, Cedric Roux wrote: >Hi, > >On 02/08/2016 11:07 AM, Fokke de Jong wrote: >> Hi all, >> >> I just wanted to give you an update on my quest for >> super-low-latency. I bit the bullet and compiled a rt-kernel. > >call me noob but did you download a special kernel >or is it the mainline with just config set in it? >I ask because at work we do realtime processing >using a low latency kernel thrown by ub*ntu and, >well I should dig the web but just to know from >someone who did it... It's the vanilla + the rt-patch + configuration. https://www.kernel.org/pub/linux/kernel/projects/rt/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] cpu spikes
PS: I forgot to mention, the lowlatency is a vanilla kernel with a special configuration, but without a realtime related patch. The default kernels of common distros should already provide some level of soft realtime ability if you boot with the 'threadirqs' option, e.g. by the /boot entry of a grub.cfg to something like 'ro' 'quiet' add 'threadirqs'. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] cpu spikes
On Mon, 1 Feb 2016 09:26:28 +0100, Christopher Arndt wrote: >> RTIRQ_NAME_LIST="usb" >> https://wiki.archlinux.org/index.php/Pro_Audio#M-Audio_Fast_Track_Pro > >How does the latter lead to the former? It latter does provide additional information regarding this card. The former is what you need in your rtirq config. More information can be found here: https://help.ubuntu.com/community/UbuntuStudio/UsbAudioDevices http://www.linux-usb.org/USB-guide/x319.html http://wiki.linuxaudio.org/wiki/system_configuration#rtirq >> http://lmgtfy.com/?q=uca222+linux > >Oh dang, hadn't thought of that! > >Thanks for nothing. So what information are you missing? http://www.catb.org/esr/faqs/smart-questions.html ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] cpu spikes
On Mon, 1 Feb 2016 07:14:46 +0100, Christopher Arndt wrote: >Am 24.01.2016 um 16:24 schrieb Harry van Haaren: >> I've written up some of the checks I generally do, perhaps browse >> that to see if there's anything there that you could check? >> http://openavproductions.com/real-time-latency-tuning/ > >I'm trying to follow that guide but I am stuck on how to find out, what >to put exactly into RTIRQ_NAME_LIST. > >How do I find out which modules are for my USB soundcard and how to >distinguish them from the ones for the mainboard soundchip? I'm also >not sure which entries in /proc/interrupts belong to my sound card. > >I have a Behringer UCA-222 and a M-Audio Fast Track Pro usb audio >interface. RTIRQ_NAME_LIST="usb" https://wiki.archlinux.org/index.php/Pro_Audio#M-Audio_Fast_Track_Pro http://lmgtfy.com/?q=uca222+linux ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] cpu spikes
PS: >On Mon, 1 Feb 2016 09:26:28 +0100, Christopher Arndt wrote: >>> RTIRQ_NAME_LIST="usb" >>> https://wiki.archlinux.org/index.php/Pro_Audio#M-Audio_Fast_Track_Pro >> >>How does the latter lead to the former? > >It latter does provide additional information regarding this card. The >former is what you need in your rtirq config. > >More information can be found here: > >https://help.ubuntu.com/community/UbuntuStudio/UsbAudioDevices >http://www.linux-usb.org/USB-guide/x319.html >http://wiki.linuxaudio.org/wiki/system_configuration#rtirq > >>> http://lmgtfy.com/?q=uca222+linux >> >>Oh dang, hadn't thought of that! >> >>Thanks for nothing. > >So what information are you missing? > >http://www.catb.org/esr/faqs/smart-questions.html IOW for detailed help the output of commands might be needed, depending to what is unclear the it could be the output of lsusb, cat /proc/interrupts, rtirq status, cat /proc/asound/cards, tree /sys/bus/usb/drivers/usb/ etc.. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] The authors of Horgand
On Sat, 05 Sep 2015 09:08:13 +0200, W.Boeke wrote: >Another reason: there are some bugs in their code (version 1.15) that >cause an immedient crash if one compiles the program from source code, >whereas if installed directly from the Ubuntu repository it works >correctly. So the code base used by Ubuntu must be different from the >source code at Github. If there should be any patches, they would be available by the source package. Start with a Debian tracker search: https://tracker.debian.org/pkg/horgand It provides the Link to the Ubuntu source package: https://launchpad.net/ubuntu/+source/horgand >The reasons of the crash are some buffer overflows, easily found using >valgrind. One patch inside the Ubuntu source package is named "03-buffer_overflow.patch". Did you compare with sourceforge? http://duck.debian.net/static/sp/h/horgand.html https://github.com/BackupTheBerlios/horgand http://sourceforge.net/projects/horgand.berlios/files/ Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] RtAudio on archlinux
On Thu, 23 Jul 2015 23:00:44 +0200, Marc Nostromo [M-.-n] wrote: That was it indeed. Thank you very much for the insight ! You are welcome! Nobody expects that an ALSA module not automatically gets loaded, it's a very annoying bug. Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] RtAudio on archlinux
On Thu, 23 Jul 2015 15:58:53 +0200, Ralf Mardorf wrote: From: Ralf Mardorf ralf.mard...@alice-dsl.net To: linux-audio-dev@lists.linuxaudio.org Subject: Re: [LAD] RtAudio on archlinux Date: Thu, 23 Jul 2015 15:49:37 +0200 X-Mailer: Claws Mail 3.12.0-6-g897a5ed (GTK+ 2.24.28; x86_64-arch-linux-gnu) On Thu, 23 Jul 2015 15:28:24 +0200, Marc Nostromo [M-.-n] wrote: [root@piewzei tests]# amidi -l Dir DeviceName IO hw:1,0,0 MS-20 Controller MIDI 1 [root@piewzei tests]# ./midiprobe Compiled APIs: Linux ALSA Current input API: Linux ALSA There are 1 MIDI input sources available. Input Port #1: Midi Through 14:0 Current output API: Linux ALSA There are 1 MIDI output ports available. Output Port #1: Midi Through 14:0 IMO this belongs to the user mailing list. Did you already try $ sudo modprobe snd_seq_midi ? https://bugs.archlinux.org/task/44812 https://bugs.archlinux.org/task/44286 Regards, Ralf PS: http://archlinuxarm.org/forum/viewtopic.php?f=23t=7739 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] RtAudio on archlinux
From: Ralf Mardorf ralf.mard...@alice-dsl.net To: linux-audio-dev@lists.linuxaudio.org Subject: Re: [LAD] RtAudio on archlinux Date: Thu, 23 Jul 2015 15:49:37 +0200 X-Mailer: Claws Mail 3.12.0-6-g897a5ed (GTK+ 2.24.28; x86_64-arch-linux-gnu) On Thu, 23 Jul 2015 15:28:24 +0200, Marc Nostromo [M-.-n] wrote: [root@piewzei tests]# amidi -l Dir DeviceName IO hw:1,0,0 MS-20 Controller MIDI 1 [root@piewzei tests]# ./midiprobe Compiled APIs: Linux ALSA Current input API: Linux ALSA There are 1 MIDI input sources available. Input Port #1: Midi Through 14:0 Current output API: Linux ALSA There are 1 MIDI output ports available. Output Port #1: Midi Through 14:0 IMO this belongs to the user mailing list. Did you already try $ sudo modprobe snd_seq_midi ? https://bugs.archlinux.org/task/44812 https://bugs.archlinux.org/task/44286 Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] GuitarSynth
On Tue, 28 Apr 2015 13:48:54 +0200, Gerald wrote: On 28.04.2015 12:31, Ralf Mardorf wrote: PS: Keep in mind that A440 not necessarily is always true. When you program, please keep in mind, that one day, when your program should be able to do what you want it to do, users should be able to chose the pitch for non-standard A in decimal place steps. well the goal is to not that dependent on the frequencies being played, but rather on the timbre/frequency envelope of the instrument. This way not the current tuning would be the serious issue, but the declining quality of the strings over time. Hi Gerald, are you sure that even playing technique wouldn't be an issue that way? Bend, slide, hammer on, pull off, muted, fingertip, plectrum or even different kinds of strings, 09 - ... nickle round wound, 10 - ... steel flat wound etc.? Ok, if you don't mix the original guitar signal with the converted signal/MIDI instrument, you don't need to mute and perhaps you can resist to play a mix of fingertip and plectrum, but you likely will slide, hammer on and pull off, not only when playing monophonic, but also when playing chords. IOW even if your software can learn what the main timbre on different strings and octaves for different tones is, does it work for guitar playing techniques or does the guitarist need to play the guitar in a keyboard style? A simple example, without or even with compressor, play g string - fret 3 and slide to fret 5, hold the tone d string - fret 3 and slide to fret 5, hammer on and pull off fret 7 do the same, but instead of fret 3, start somewhere behind fret 12, at least without compression already the loudness could become an issue, while you still clearly hear changing frequencies. That were just 2 tones. Now play e string - fret 3 hold the tone b string - fret 3 hammer on and pull off fret 5 g string - fret 4 hold the tone d string - fret 5 hold the tone If you like you could slide the g chord to an a chord before you do the hammering. Do this on different positions, e.g. play a c chord this way. Perhaps I misunderstand what timbre/frequency envelope is. Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] GuitarSynth
On Tue, 28 Apr 2015 17:10:55 +0200, Gerald wrote: Hi Ralf, this works pretty good with my lowpass-rectify-aubio pitch detection. What I want to work on (once GuitarSynth is ported to DPF) is a source-filter analysis (see U Zölzer: DAFX) to extract the spectral envelope (timbre) of the guitar. As Zölzer putts it, it is then possible to obtain a neutral frequency analysis, that just the tones/frequencies without their attenuation due to playing technique. This is done simply by dividing the FFT'd input signal by the envelope. I think that should be done before the pitch detection. And anyway I want to convolve/multiply the envelope with the synths (as an option in the GUI). Then GuitarSynth will really be a guitar synth ;) Gerald On 28.04.2015 15:58, Ralf Mardorf wrote: A simple example, without or even with compressor, play g string - fret 3 and slide to fret 5, hold the tone d string - fret 3 and slide to fret 5, hammer on and pull off fret 7 I only build your software until now, since I don't had/have time to test it at the moment. But I'll test latest pull from git ASAP. At the moment I only can confirm, that I was able to launch this versions and they showed up in jackd :): [rocketmouse@archlinux ~]$ ls -hanG /usr/src/GuitarSynth/build/ total 344K drwxr-xr-x 2 1000 4.0K Apr 25 19:10 . drwxr-xr-x 4 1000 4.0K Apr 25 10:29 .. -rwxr-xr-x 1 1000 77K Apr 18 14:39 GuitarSynth2.0a683c4 -rwxr-xr-x 1 1000 77K Apr 19 19:24 GuitarSynth2.9ee232d -rwxr-xr-x 1 1000 77K Apr 18 21:06 GuitarSynth2.dcd272d -rwxr-xr-x 1 1000 77K Apr 25 10:32 GuitarSynth2-ge7356fc Did you already release a git version that is able to handle polyphony? My apologies for not testing it. I promise I'll do ASAP. Your project is cool, very interesting. I don't like to pay for a hex pickup that needs to be installed to my vintage guitar and that in addition needs a stand alone synth to convert to MIDI. I would like some kind of converter that is able to e.g. use my Oberheim Matrix-1000, without damaging my guitar. The Matrix-1000 has got a guitar mode! It's one of my best synth, but I try to use it as less as possible, since if ever a Curtis/CEM chip should get broken, there's no chance for me to pay for a spare part. https://en.wikipedia.org/wiki/Doug_Curtis ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] GuitarSynth
PS: Keep in mind that A440 not necessarily is always true. When you program, please keep in mind, that one day, when your program should be able to do what you want it to do, users should be able to chose the pitch for non-standard A in decimal place steps. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] GuitarSynth
On Tue, 28 Apr 2015 01:55:04 +0100, Harry van Haaren wrote: On Tue, Apr 28, 2015 at 12:57 AM, Tim E. Real termt...@rogers.com wrote: The effect is striking. You can hear it without even plugging the guitar in. As you adjust the pickup ever higher, and pluck the strings, you can hear the horrible overtones from the frequency splitting. Wow really? I didn't know that.. but I'll try it tomorrow! Thanks for the 'note' ;) -Harry I adjust the highs of my single coils depending to what I do. I anyway have to do this all the times, since they lower when playing. A while back I sampled my guitar for the sound sampler of my tablet PC. Since I needed a blues g hexatonic, I decided to sample the scale close to the twelfth fret (IOW around the thirteenth and fifteens fret), because a single coil close to the neck then produces an unique sound. Indeed, when playing a guitar I seldom want the noise caused by to high coils, but when recording it to make a sampler sound it's wanted for one or he other tone, dirt makes a sound sample sound more natural. The day before I adjusted action and intonation. Too funny, just one day, perhaps caused by another temperature of the room and the intonation that was nearly perfect the day before, wasn't perfect anymore. I guess intonation of guitars could become a serious issue for converters. I place value on a good intonation, but if the tuning is perfect when playing open and for the twelfth fret, the tuning for the frets between open and twelfth fret still could be disastrous. I only can fit the intonation to the way I play my guitar, if somebody else should prefer to play chords and scales in other positions, the intonation likely is broken. However, the e guitar at least has a relatively good intonation. My classical guitar has got a very unique, odd intonation ;) and there's no action to adjust it. Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio continued
On Mon, 27 Apr 2015 02:31:06 +0200, t...@trellis.ch wrote: -font size -color contrast Theoretical this should be solvable by the font sizes and the colour theme the user does chose for the DE/WM. Colour themes shouldn't get broken after updates of the DE/WM and if fonts are large, windows automatically should add scroll bars if needed. Unfortunately several apps don't care about the users DE/WM settings without providing good themes on their own and unfortunately the Linux DEs are a PITA because each upgrade might break the theme and WMs are often not that easy to configure as DEs are. However, I never noticed an issue caused by an upgrade of openbox and JWM, but Xfce4 became a PITA. A completely no-go are all those apps that try to provide photo-realistic GUIs, that fake to be analog hardware. Apart from the bad taste of this kind of theme art, the bigger issues is, that this kind of theme art often make fonts and controls less good visible. It seems to be out of style to work in front of a monitor at daylight while wearing reading glasses. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] GuitarSynth
On Fri, 24 Apr 2015 23:13:12 -0400, Tim E. Real wrote: To reduce latency I even tried putting the guitar through a standard time-domain pitch shifter (up one octave) and then into the detector. Not bad, so so. Since dead strings aren't an option for me, this is something I'll test for monophonic converters, because they also suffer from accuracy and latency. I never tested this. Nice idea. JFTR, if I'm short of money, I boil dead guitar strings in water. As long as they only suffered from skin fat and particles of skin and they aren't worn out or suffer from oxidation, this refreshes the strings without a side effect. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On Sat, 25 Apr 2015 08:50:21 +0100, Will Godfrey wrote: One of my pet hates is erratic implementation of tooltips... that can't be disabled! Tooltips showing the value instead of a description of the option IMO are good. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On Fri, 24 Apr 2015 23:55:31 -0400, Tim E. Real wrote: My centre-screen technique is in fact limited to half-screen The real desk might be limited to, e.g. a mini mouse pad on a synth, so the mouse wheel option could be very important to avoid huge mouse movements. It's not only the screen that is a limitation, the desk/mouse pad could be very, very small. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On Sat, 25 Apr 2015 10:23:14 +0200, Thorsten Wilms wrote: https://afaikblog.files.wordpress.com/2013/01/date-and-time.png We already know a solution since decades. Checkboxes +1 I see that on my iPad every day and never become used to it, there's always doubt. I've never noticed such a bad thing by the Linux desktop PC apps I'm using. Reminds me of consumer hifi gear were sometimes inputs are outputs and outputs are inputs. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On Fri, 24 Apr 2015 20:33:05 -0700 (PDT), Len Ovens wrote: another idea for a touch screen: 1 touch control with finger one. 2 put finger two some distance away. 3 move finger two towards control to decrease value or farther away to increase value. 4 lift both fingers. I am not sure if lift order would matter. (it shouldn't) I do not know how long it would take to learn this so it was natural to use. Hi Len, it conflicts with gestures, if you by accident don't touch the control and you do the two finger pinch, something unpleasant could happen. IMO 1 touch the control, it gets a colour that signals that it's activated 2 put a finger some distance away 3 move towards control to decrease value or farther away to increase value 4 touch the control again, to deactivate it, colour becomes normal Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On Fri, 24 Apr 2015 22:18:57 -0400, Tim E. Real wrote: What do you think? Hi Tim, if the mouse courser reaches a screen border, the mouse movement should continue to increase/decrease the fader/knob value, but the mouse cursor should stay at the boarder, without movement, close to the knob/fader. Repositioning it, far a way from the area were we are working isn't good. There's no need to see a moving mouse cursor, since the fader/knob is moving. 2 Cents, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On Sat, 25 Apr 2015 10:53:07 +, Fons Adriaensen wrote: Second, because that way I will learn the relation between the values and the resulting sound, and be able to do the same on different HW or SW without having to search blindly by twiddling the knobs. Couldn't say better. As I pointed out by my synth attack sync example: it can help to at least get coarse results very quickly This is much more true for good EQs. Sometimes I need to search a culprit using a narrow bandwidth [1] using a parametric's EQ Q and checking different frequencies, but at least a coarse mix can be done without listening. [1] Allow me to misuse this word ;). http://www.sengpielaudio.com/calculator-bandwidth.htm It's not needed to know such things, if you get a feeling for it by practise. Regarding the toy GUIs that show a graph. I'm not against graphs, but they aren't (always) useful and I don't had them over several decades when using analog mixing consoles. Regards, Ralf PS: IMO tablet PCs should be excluded from a discussion about Linux audio, that usually doesn't run on tablet PCs. Touch screens have other pitfalls. http://www.xewton.com/musicstudio/forum/viewtopic.php?f=3t=2524 JFTR I'm Unknown Crewman. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On Tue, 21 Apr 2015 08:43:15 +0200, Thijs van severen wrote: i dont think it has to be modal, and i'm also curious what other thing you will be doing in those 3-5 sec that the splash is there surprise me :-) Maybe taking a look at the messages displayed in the terminal emulation where the app was launched ;). Depending on what some apps need to establish, before the next app can be launched, we sometimes need to add delay ... roxterm --tab -n ♪ foo -e foo --option=bar ; sleep 2 The app already might be running, just establishing some things might take a while after the splash screen already disappeared. It e.g. might take two seconds after loading _data_ (not the app) and the app likely displays information by the terminal emulation output or by a log message window. The script/terminal emulation approach might be out of fashion, anyway, an app still could display a splash screen, while the important part of the app already segfaulted. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Android's 10 Millisecond Problem
On Thu, 16 Apr 2015 09:41:11 -0600, John Hammen wrote: interesting article on Android's latency http://superpowered.com/androidaudiopathlatency/ via Hacker News news.ycombinator.com Thank you for sharing this. Assumed Android devices one day should be usable for audio, I wonder if they suffer from a known iPad issue too. It's true that latency isn't an issue when using an iPad, but battery charge could become an issue. I still need to use a stop watch, but I guess after around 5 or 6 hours and sometimes even after less hours, my iPad 2 turns off. If the iPad then is plugged to the power supply, it anyway can't be used. Loss of battery charge by the power consumption of a DAW/MIDI sequencer - Audiobus - parametric EQ chain needs more power, than the 10 W power supply does recharge the battery. IOW for Apple tablet PCs compulsory breaks interrupt creative work for hours, as soon as the battery needs to be recharged. Apple devices need much improvement too, not regarding latency, but regarding the power consumption. They are far away from being perfect. The OS might be good, but the hardware isn't. I read that people using the iPad 3 for office work, stopped using them, regarding the power supply issue. Is it possible to run an Android device by a power supply, when the battery is empty? Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Bulk] Linux Kernel Lockup
On Sat, 29 Nov 2014 23:17:48 + Will Godfrey willgodf...@musically.me.uk wrote: I don't know if anyone here has heard about this. I discovered the link quite by accident. http://lkml.iu.edu/hypermail/linux/kernel/1411.3/02866.html If you're using 3.17 it might be an idea to step back to 3.16, which so far seems to be OK. I've been using 3.16 for several months now and not had any problems. $ pacman -Q linux linux-rt linux-rt-lts linux 3.17.4-1 linux-rt 3.14.25_rt22-1 linux-rt-lts 3.10.58_rt62-2 No problems with 3.17.4 and all versions 3.17.4 here, with one exception, building modules for the outdated virtualbox version 4.3.12 still works for kernels = 3.16 (with and without rt patch), but doesn't work for 3.17 kernels. Building the virtualbox modules for kernels 3.17 works for current version of virtualbox, unfortunately USB is broken for all versions of virtualbox 4.3.12. A while ago rt kernels 3.8.13-rt locked my AMD machine, but that doesn't happen any more, e.g. the above listed linux-rt are ok, at least for non-audio work, I didn't used them for audio. However, some distros for good reasons provide LTS kernels, for Arch Linux it is $ pacman -Si linux-lts | grep Version Version: 3.14.25-1 Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Fwd: Re: How can a LV2 plugin know on what host's MIDI Channel it's on?
I agree with Len. On Thu, 2014-10-16 at 12:29 -0700, Len Ovens wrote: That control could have an option to accept all channels too so that the host could do filtering. JFTR accept all channels, as if they were one channel is named omni mode :). ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Bulk] Re: How can a LV2 plugin know on what host's MIDI Channel it's on?
On Fri, 2014-10-17 at 08:25 +0100, Phil CM wrote: The fact that when I put it on a MIDI track (and the hosts decide witch MIDI channel this track sends messages on) I can hear it without telling him said channel (and I only hear it on that track)..? Len explained it ;). Omni mode: http://lists.linuxaudio.org/pipermail/linux-audio-dev/2014-October/035575.html ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Bulk] Re: How can a LV2 plugin know on what host's MIDI Channel it's on?
On Fri, 2014-10-17 at 01:12 -0700, Len Ovens wrote: I would suggest that Calf Monosynth is channel agnostic. That is it ignores the channel information and uses midi events for any channel. Len explained it ;). Omni mode: http://lists.linuxaudio.org/pipermail/linux-audio-dev/2014-October/035575.html It can be tested, if it is done that way, by recording or editing two or more channels with one Qtractor MIDI track. Btw. Qtractor's track properties dialog allows to select channel 1 to 16, while other sequencers might provide to select from 1 to 16 + any or all, Qtractor provides to check omni. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [OT] Duplicate messages originating from ds...@snarchi.io
On Sun, 2014-10-05 at 22:00 +, Fons Adriaensen wrote: Hello all, Since some time I do get duplicate messages on this list for example the last one just a few minutes ago: Date: Sun, 5 Oct 2014 23:35:21 +0200 From ds...@snarchi.io Sun Oct 5 21:35:55 2014 From: t...@trellis.ch To: Fons Adriaensen f...@linuxaudio.org Cc: linux-audio-dev@lists.linuxaudio.org This seems to happen only to messages which are a reply to one I sent. The 'ds...@snarchi.io' address seems to be related to 'marcochapeau', a name I've seen before on this list. I just wonder if I'm the only one getting these. You are not alone, happens on LAU too. It would be better if people would reply to the lists only. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [OT] Duplicate messages originating from ds...@snarchi.io
Forwarded Message From: Len Ovens l...@ovenwerks.net To: Fons Adriaensen f...@linuxaudio.org Cc: Linux Audio Developers linux-audio-dev@lists.linuxaudio.org When I receive such mails from you Len, I get one mail directly from you and a second mail from the mailing list. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [OT] Duplicate messages originating from ds...@snarchi.io
On Tue, 2014-10-14 at 17:36 +0200, Ralf Mardorf wrote: On Sat, 2014-10-11 at 15:40 +0200, hermann meyer wrote: Am 06.10.2014 02:51, schrieb Len Ovens: On Sun, 5 Oct 2014, Fons Adriaensen wrote: Hello all, Since some time I do get duplicate messages on this list for example the last one just a few minutes ago: Date: Sun, 5 Oct 2014 23:35:21 +0200 From ds...@snarchi.io Sun Oct 5 21:35:55 2014 From: t...@trellis.ch To: Fons Adriaensen f...@linuxaudio.org Cc: linux-audio-dev@lists.linuxaudio.org This seems to happen only to messages which are a reply to one I sent. The 'ds...@snarchi.io' address seems to be related to 'marcochapeau', a name I've seen before on this list. I just wonder if I'm the only one getting these. I have been seeing them too. I may have even seen one triplicate. They don't seem to be in the archives though. I haven't kept track of them though. -- Len Ovens www.ovenwerks.net The current zitaretuner thread is full of duplicated Messages here, in fact I receive them 4 times each, [LAU] [LAD] . . , [LAU] [LAD] . . ., [LAD] [LAU] . . . , [LAD] . . . . At least those which reply to LAU and LAD. Because LAU sends to LAD and LAD sends to LAU ;), two of the 4 mails have both footers. It can't be like that ;), but it looks like that. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Experience driven design and Linux Audio
On Fri, 2014-10-03 at 17:09 +1000, Patrick Shirkey wrote: On Fri, October 3, 2014 7:22 am, Len Ovens wrote: snip SHould Linux target those who only see a comodity? WHo are only looking to have what their idol uses? Or who want the cheapest one that works? The stuff already out there will be what gets bought. Developing HW with Linux is like developing with any other OS, it requires innovation and lots of support. The linux HW has to have what nothing else does and the something has to be seen as needed. Lets see how the mod duo does. I have asked people who already have similar gear about the mod boxes and while they are interested in the platform they are put off by the price. Until they reach the economies of scale to be price competitive there will be a small market. Especially if trying to sell to the existing Linux peeps who are generally pretty cheap when it comes to actually parting with their own personal cash. Several people have tried to tap the market with expensive hardware and had pretty dismal results. However if we look at the success of the low end DIY market ex arduino, rasp pi, rockchip, allwinner that is a pretty good success story. Whats wrong with the price? Assumed the hardware should be ok and there would be a sane selection of high quality effects needed by musicians (instead of hundreds of music pedals [1]), it isn't expensive. [1] An irritating slogan, I suspect it would be hard just to name 50 effect pedals, let alone hundreds. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Experience driven design and Linux Audio
On Fri, 2014-10-03 at 17:59 -0700, Len Ovens wrote: http://www.zoom.co.jp/products/ms-100bt Wow! Perhaps shopping new effects isn't that important for many musicians: http://www.thomann.de/gb/zoom_multi_stomp_ms50g.htm An advantage of the MOD Duo clearly is, that it's possible to connect Expression Pedals and a footswitch extensor. OTOH for the low price of the Zoom effects it's possible to buy several of those devices, this would have the advantage, that if one device should fail on stage, the musician wouldn't be completely lost. The Advantage of the Zooms likely is the compact design, simply replace one of your Boss boxes in the case with one of the Zoom effects. Zoom is an established known company, if weak points, such as the display should fail within the period of warranty, you can assume that the company still will exists. You can't assume this for new companies. I suspect that neither all available Linux effects, nor all the Zoom effects will satisfy musicians, compared to some classic stomp box effects, but both, a Linux and a Zoom likely could replace some effects. Btw. I guess I'll order a MS-50G, resp. take a look if there are other similar products available in this price range. Assumed I should dislike it at a time when it isn't possible to send it back to the dealer, it likely would be possible to sell it for half of the price, such a drop is passable. Resume: For us it's nice to get a device that is available to use open source. Is this from interest for a majority of musicians? If not, than the MOD duo never would become able to compete for the cost. However, if the MOD duo should really provide something special, that isn't provided by other products, the price still would be ok. [snip] Open-source seems like a somewhat dubious format for pedals, since many cheap digital multi-effects processors already exist and are generally shunned by people who prefer analog circuitry. - http://blog.pedalfinder.com/2014/09/443/ There are simply analog devices enjoying cult status for good reasons, but some of the new digital devices are accepted too, they are not shunned per se. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Experience driven design and Linux Audio
On Thu, 2014-10-02 at 10:24 +0100, gordon...@gjcp.net wrote: Ever wonder why your DX21 has only got eight algorithms by which the operators may be combined? *That's* why. That's a reasoning just from your point of view, but not the real reasoning. Btw. the DX21 provides 4 operators. But the flagship is the DX7, with 6 operators and 32 algorithms, usually feedback is given to 1 operator only, but 2 algorithms provide a grouped feedback and there are various ways how operators modulate other operators. The reason why it's different for the DX21 are cost concerns. Programming the DX7 for most users was to complicated, because there isn't a usable user interface, just a very small display and a few switches, quasi the Unity of synthesizer user interfaces. A modular DX7 or better DX2014 with cables and potentiometers and programming it would become enjoyable, but the synth would become much too expensive. Analogies or comparisons don't work. There are reasons why completely contrary designs could be as good as the other. There isn't a theory of everything for functionality of design. There are no knobs on a piano, but using a piano for me would be much more complicated, because a normal piano can't be connected to a sequencer, so playing it for a guitarist like me is hard to do. Why doesn't a piano provide a neck as a guitar does? I now could make some reasoning from a guitarist's point of view and ignore the fact that a piano and a guitar are just different tools for musicians. Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Linux audio jobs/companies?
On Mon, 2014-09-29 at 12:22 +0200, Florian Paul Schmidt wrote: On 27.09.2014 16:59, Ralf Mardorf wrote: A lot of consumer audio-video stand alone gear is using Linux, e.g. television satellite receivers. IMO this market might be more interesting when searching for a job, than the pro-audio market or Internet presences are. Lip-sync is an issue, assumed you should have the abilities to fix it, you likely would find a job. Can you elaborate on that? What exactly is the problem? And what kind of solutions are people looking for? I don't know if the Linux kernels used for audio-video consumer gear are used for audio and video processing, perhaps they are just used to provide menus etc., but since the end of the 90s I never experienced the good audio and video sync we had with German terrestrial analog television. All analog and digital satellite and digital terrestrial receivers I've seen didn't provide acceptable sync. Assumed at least some of those receiver should do the audio and video processing using Linux too, a smart solution to fix such issues, not by just providing fixed delays, but by detecting the exact drift and automatically fixing it, might be from interest for the consumer gear companies. Perhaps, they wouldn't care about a smart way to fix it, OTOH for colour correctness at least Germany cared, so we once upon a time got PAL. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Linux audio jobs/companies?
On Mon, 2014-09-29 at 12:41 +0200, raf wrote: Le 29 sept. 2014 à 12:34, Ralf Mardorf ralf.mard...@rocketmail.com a écrit : On Mon, 2014-09-29 at 12:22 +0200, Florian Paul Schmidt wrote: On 27.09.2014 16:59, Ralf Mardorf wrote: A lot of consumer audio-video stand alone gear is using Linux, e.g. television satellite receivers. IMO this market might be more interesting when searching for a job, than the pro-audio market or Internet presences are. Lip-sync is an issue, assumed you should have the abilities to fix it, you likely would find a job. Can you elaborate on that? What exactly is the problem? And what kind of solutions are people looking for? I don't know if the Linux kernels used for audio-video consumer gear are used for audio and video processing, perhaps they are just used to provide menus etc., but since the end of the 90s I never experienced the good audio and video sync we had with German terrestrial analog television. All analog and digital satellite and digital terrestrial receivers I've seen didn't provide acceptable sync. Assumed at least some of those receiver should do the audio and video processing using Linux too, a smart solution to fix such issues, not by just providing fixed delays, but by detecting the exact drift and automatically fixing it, might be from interest for the consumer gear companies. Perhaps, they wouldn't care about a smart way to fix it, OTOH for colour correctness at least Germany cared, so we once upon a time got PAL. you did see that ? I'm surprised. Which brand ? I've worked for two years on the A/V testbenches for sagemcom making a whole lot of digital satellite receivers and never noticed that. Until two years ago they used an RT system on STM32 processors. The move to embedded linux was quite new, maybe introducing this issue. I don't remember the brands of the satellite receivers I owned (discounter thingies), but a friend repairs receivers, so I've seen a lot. Many people in German switched to DVB-T, I can see it on my THOMSON DTI series 500. It could differ for different broadcasts of the same station. My claim isn't that the receivers cause the sync issue. I remember that at least some satellite receivers provided to manually set a delay, but AFAIK no auto-syncing option does exist (similar as PAL to ensure colour stability). My DVB-T receiver seems even not to provide to set a delay manually. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Linux audio jobs/companies?
On Mon, 2014-09-29 at 13:47 +0200, Ralf Mardorf wrote: On Mon, 2014-09-29 at 12:41 +0200, raf wrote: Le 29 sept. 2014 à 12:34, Ralf Mardorf ralf.mard...@rocketmail.com a écrit : On Mon, 2014-09-29 at 12:22 +0200, Florian Paul Schmidt wrote: On 27.09.2014 16:59, Ralf Mardorf wrote: A lot of consumer audio-video stand alone gear is using Linux, e.g. television satellite receivers. IMO this market might be more interesting when searching for a job, than the pro-audio market or Internet presences are. Lip-sync is an issue, assumed you should have the abilities to fix it, you likely would find a job. Can you elaborate on that? What exactly is the problem? And what kind of solutions are people looking for? I don't know if the Linux kernels used for audio-video consumer gear are used for audio and video processing, perhaps they are just used to provide menus etc., but since the end of the 90s I never experienced the good audio and video sync we had with German terrestrial analog television. All analog and digital satellite and digital terrestrial receivers I've seen didn't provide acceptable sync. Assumed at least some of those receiver should do the audio and video processing using Linux too, a smart solution to fix such issues, not by just providing fixed delays, but by detecting the exact drift and automatically fixing it, might be from interest for the consumer gear companies. Perhaps, they wouldn't care about a smart way to fix it, OTOH for colour correctness at least Germany cared, so we once upon a time got PAL. you did see that ? I'm surprised. Which brand ? I've worked for two years on the A/V testbenches for sagemcom making a whole lot of digital satellite receivers and never noticed that. Until two years ago they used an RT system on STM32 processors. The move to embedded linux was quite new, maybe introducing this issue. I don't remember the brands of the satellite receivers I owned (discounter thingies), but a friend repairs receivers, so I've seen a lot. Many people in German switched to DVB-T, I can see it on my THOMSON DTI series 500. It could differ for different broadcasts of the same station. My claim isn't that the receivers cause the sync issue. I remember that at least some satellite receivers provided to manually set a delay, but AFAIK no auto-syncing option does exist (similar as PAL to ensure colour stability). My DVB-T receiver seems even not to provide to set a delay manually. And I don't claim that THOMSON does use Linux, perhaps, perhaps not. I only want to point out that lip-sync is a known issue in Germany and that lot of consumer gear does use Linux. The lip-sync issue might be caused by the station or anywhere in the chain from station to receiver. If somebody would event something, that could automatically fix it, this perhaps could become the next great invention, after the invention of PAL. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Linux audio jobs/companies?
On Mon, 2014-09-29 at 13:58 +0200, Nils wrote: ralfed I was asked and replied ;). I would prefer not to talk about television. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Linux audio jobs/companies?
On Sat, 2014-09-27 at 10:27 -0400, Bill Gribble wrote: It's job hunting time, and while I am skeptical that there are very many paying jobs for Linux audio developers out there, I thought I'd at least ask on this list. What companies are doing work in the Linux audio universe? Or, on the other side, anybody know of interesting music-instrument/audio companies located in or around NYC (where I live) who might need Linux folks for their web presence or other online stuff? Any tips appreciated! A lot of consumer audio-video stand alone gear is using Linux, e.g. television satellite receivers. IMO this market might be more interesting when searching for a job, than the pro-audio market or Internet presences are. Just 2 Cents ;), Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Linux audio jobs/companies?
On Sat, 2014-09-27 at 16:39 +0200, Ralf Mardorf wrote: On Sat, 2014-09-27 at 10:27 -0400, Bill Gribble wrote: It's job hunting time, and while I am skeptical that there are very many paying jobs for Linux audio developers out there, I thought I'd at least ask on this list. What companies are doing work in the Linux audio universe? Or, on the other side, anybody know of interesting music-instrument/audio companies located in or around NYC (where I live) who might need Linux folks for their web presence or other online stuff? Any tips appreciated! A lot of consumer audio-video stand alone gear is using Linux, e.g. television satellite receivers. IMO this market might be more interesting when searching for a job, than the pro-audio market or Internet presences are. Lip-sync is an issue, assumed you should have the abilities to fix it, you likely would find a job. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Bulk] Re: Digital Effects
On Thu, 2014-09-04 at 15:37 +0800, Brad Campbell wrote: One thing I told years ago by a gnarled old recording engineer was always put plenty of reverb into the vocalists monitor. I took this on-board and while I always record may parts as dry as is practical, I always have plenty of FX in the monitor. I find it makes me sing better and play better/cleaner. Sometimes the psychologically effect does help, but in general this is a mistake. Drawing a picture large and making it smaller for the release usually is better than drawing a picture small and enlarge it for the release. For my instrument parts reverb or echo multiplies the tiniest of mistakes and therefore I concentrate a lot harder on not making them That does only work, if you are within one scale, your music is based much on clock of keys. If not, the result likely is terrible, reverb or feedback delays could be disastrous. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Bulk] Re: [Bulk] Re: Digital Effects
On Thu, 2014-09-04 at 21:27 +0200, Lieven Moors wrote: On Thu, Sep 04, 2014 at 10:01:31AM +0200, Ralf Mardorf wrote: On Thu, 2014-09-04 at 15:37 +0800, Brad Campbell wrote: One thing I told years ago by a gnarled old recording engineer was always put plenty of reverb into the vocalists monitor. I took this on-board and while I always record may parts as dry as is practical, I always have plenty of FX in the monitor. I find it makes me sing better and play better/cleaner. Sometimes the psychologically effect does help, but in general this is a mistake. Drawing a picture large and making it smaller for the release usually is better than drawing a picture small and enlarge it for the release. For my instrument parts reverb or echo multiplies the tiniest of mistakes and therefore I concentrate a lot harder on not making them That does only work, if you are within one scale, your music is based much on clock of keys. If not, the result likely is terrible, reverb or feedback delays could be disastrous. Oh Ralf... you are SO cool. Pardon, you are right, a good musician is unable to play her/his instrument without effects for the monitoring, especially when interfering with long reverbs and delays, it's much easier to sing or play an instrument. It's common practise to add reverb and delay to help singers and instrumentalists to get aware of their mistakes and to help them to do a better job. My notes are completely wrong and it's absolutely good to add intensive time related effects to the monitoring. It can't harm by delay to add some notes from the 1/4 bar before to the next ones. My apologies. Now I remember all professional studios and musicians do that smart trick, they add as much effects as possible to the monitoring. Don't forget to add much distortion to the guitar, it covers mistakes when playing scales and allows beginners to play much faster. Later you simply do the mix without the distortion, delay, reverb, the result likely is amazing. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Software sound
On Sat, 2014-08-30 at 10:13 +0100, W.Boeke wrote: [snip] I'm able to edit existing Yoshimi sounds, but that's not my point. My point is to add a vector control that is similar to the one provided by the Yamaha TG33, then you exactly would get a musician friendly control to edit sounds. People often can't imagine how effectively different sounds can be produced by recording a mixing sequence with a joystick, even if it only records volume and fine tune. There is no easier effective sound editing than to record a volume/pitch mix with a vector control. The joystick could be provided virtually by a GUI, as done by Alchemy http://www.camelaudio.com/images/ios/1-1-35/iphone/alchemy-mobile-iphone-1-1-35-xy-pads.png . Instead of using Yoshimi simply providing a MIDI filter that can record vector movements and store them and sends it to 4 other synth. The vector simply could send CC data for volume. IOW the MIDI filter, perhaps using the same CC as the TG33, IOW CC 16 vector x-axis and CC 17 vector y-axis are translated to CC 7 volume for 4 different synths and then is send to them. The MIDI filter will record the sequence of the vector control and MIDI channels of the 4 synth in presets. JFTR have you ever used a vector controlled synth such as the TG33? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Software sound
On Sun, 2014-08-31 at 12:21 +0200, Tim Goetze wrote: [W.Boeke] Compared to the available technical possibilities of the past, software designers nowadays have a much easier life. A computer and a MIDI keyboard is all you need, you can try all kinds of sound creation, so why should you stick trying to reproduce the sounds of yore? I definitely agree with the sentiment but it's not an easy task to purely digitally create timbres as rich, complex and pleasing as produced by analog, let alone physical (non-electronic) instruments. For example, analog op-amp or diode saturation is quite simple to realise and capable of producing anything from very smooth harmonic extension to screaming distortion. The digital equivalent needs to be oversampled, complicating things greatly. [snip] Wait a moment. Building an anlog synth by electronic circuits could be harder or easier to do, it depends to the skills of the developer. For software designers in the past hard real-time MIDI was easier to provide, than it is to provide nowadays. There are many factors important. Several times even galvanic isolation for the MIDI interfaces provided by old gear and by modern USB devices was mentioned. What ever in theory could be programmed, even the different output amplifiers of different real synth already could provide differences for the sound, one computer, using the same sound card for several virtual instruments only would provide, if somebody would care about it. Not to mention CEM/Curtis filters etc.. Understanding an ADSR with or without a graphic display shouldn't be an issue for musicians, it might be hard for some beginners. Anyway, that is provided since decades, even the faders of a simple ADSR already show the envelope by the fader positions. I suspect the OP has got less experiences with professional gear, it abilities and what professional musicians do need. It can't be repeated often enough. The way that was provided already in the 80s is a vector control. Everybody can create sounds by a vector control, absolutely no knowledge is needed. For using an ADSR there's the need to understand very much, less how the envelope does look like, more important is what is controlled by the envelope and that the envelop might variate to the dynamic of the musicians playing, by the played note number etc.. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Software sound
PS: So to provide a new electric instrument even nowadays not only a computer and a keyboard is needed. The virtual instrument might work on some distros and on other distros it might not work. It might work with some computers and sound cards and MIDI interfaces, but not work with other hardware. If somebody want's to provide the complete solution it's not just having a computer and keyboard. Even when a software developer just cares for the studio in the box and maintains it for several releases of just one distro, but does not care about using it with external gear, some algorithm (user friendly or not) might need much computer resources, could cause unwanted latency etc. pp. In the end building a synth by a circuit layout and some semiconductor could be easier to do, than to provide software with the guarantee that the software will do what it should do, since a wrong MIDI interface already could cause ground loops, assumed somebody want's to connect the virtual synth with what external gear ever. Making new sounds for a synth always needs a learning curve. A good GUI isn't the solution, if a user e.g. doesn't understand how a filter does work, the best GUI for a filter can't help. What ever synthesis is used, there is the need to have knowledge, no new synthesis will be a solution for this issue. The only way are workarounds such as the vector control, or anything comparable to it. Computers can't solve higher-ranking issues caused by nature. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Software sound
On Thu, 2014-08-28 at 14:52 +0100, W.Boeke wrote: You didn't really read my post didn't you? You are slghtly off-topic, it reads like the catalogus of a keyboard shop. Look at the name of this forum. Linux: that is about software. Developers: that are people interested in creating something new, not in purchaging all kinds of gear. What I wanted to point out is, that one feature for virtual Linux synth is missing, that could do what you are looking for. By joystick, mouse and/or touchscreen provide to record mix sequences of sound volumes, (de)tuning, to manipulate filters, effects and/or the arpeggiator and let this mix become part of the sound that is stored to a preset. Yoshimi would be a good candidate to add such a feature. My point is, that there are already good solutions provided by old synth and by proprietary virtual synths for other OSs. You could adapt it and provide this for Linux, use a synth like Yoshimi, use the available sounds and let users make new sounds by using mouse, joystick and/or touchscreens, just by recording mix sequences that manipulate the volume or a filter etc.. Vector thingies like this could provide amazing sounds and are available since the 80th for stand alone synth, proprietary virtual synth adapted this. I'm not aware that there are virtual Linux synth providing it. To generate a new sound by what ever synthesis needs knowhow and some effort, using existing sounds and manipulate them using a joystick or similar is easy to do. Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Ardour sampler feature?
On Tue, 2014-08-26 at 12:39 -0500, Devin Venable wrote: Maybe I'm missing it, but I don't think such as feature as I'm about to describe exists. I'm making lots of use of the MIDI track functionality. I find myself wanting to take an audio segment, convert it to sample, and then use it on a midi track. I don't believe there is a way to do this without the aide of an external sampler program. My dream feature? Click on segment, select convert to sample and a new midi track appears linked to a plugin sampler, ready to play. While I guess to understand the idea, I disagree and recommend to handle this tasks individually/manually. I don't use Ardour for MIDI, but it doesn't mater regarding to my opinion about your feature request. Good samples need layers, how should layers be detected? Your request likely is possible as long as no features a sampler should provide are needed, IOW a sampler automagiocally only could provide what you can do by copying the segment, so simply copy the segment, is less resource hungry. As soon as you want the features a sampler provides, I doubt that just move file.wave to sampler-midi note on x could do the trick. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Half-OT: Fader mapping - was - Ardour MIDI tracer
On Sun, 2014-08-24 at 22:56 +0200, hermann meyer wrote: why musicians could prefer the digital way, if at least the end up in a digital media. When recording a guitar at midnight in a rental apartment I play my guitar directly connected to the mixing console, resp. some preamplification is better before using the mixer. Sometimes amp and speaker simulations can be used, but often they are too sluggish. EQs digital or analog) and early reflections (digital) often are more promising. I'm not against digital gear for guitars, OTOH tube gear has some advantages and even analog transistor gear. I mentioned the Boss Sustainer and Turbo Overdrive. Both effects can be done digital too, but the advantage when using those effects is, that you automatically get a preamp. The Hughes Kettner tube preamp is much better. At home we usually can not record a guitar amp, in a studio we can do. A flight simulator is good to practise flying, but if you want to travel, you need to use a real plane. There is nothing like a tube emulation. You can not use a mixer or sound card input with a completely different responding quality and frequency response than those provided by tubes and Celestion speakers and use an algorithm to simulate something that is missing. It's possible to handle the frequencies, when there are only frequencies to cut, but impossible to emulate a missing responding quality. For guitar the simulations are to sluggish, the responding quality of the sound cards or mixers are different to those of tube amps. Regarding the tube microphone emulation, let your Sure mic sound like a Neuman or Brauner, it's not only the tube, but much more the missing frequency response of the capsule. On Sun, 2014-08-24 at 22:53 +0100, James Morris wrote: Bring out the pitchforks, someone dares to not keep up with the times, burn him at the stake! You are missing the context. I'm pro old equipment, but against equipment that tries to fake vintage gear, claiming to use modern methods, while it even doesn't use the available algorithms. And again, you can simulate a flight, but you can't travel using a flight simulator. IOW if you know what to do, you can provide digital EQs and things like that, but you can not provide preamp and amp simulation, when the preamp from the mixer or sound card simply can not do what's needed for guitar. Perhaps you noticed that one of the threads is about pickups and the different sound, when using a guitar amp and when using other gear. I'm not a bonehead, I simply confront you with the technical facts. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
