Hi everyone,
Some of you might have noticed, we're having issues delivering mailing lists
posts to gmail users (it can be fairly random). I'm also having similar
issues at work and on my own server. It seems gmail has tightened their
filtering rules a bit and generate quite the amount of backscatter emails
which generally results in mailman accounts being disabled.
TL;DR
mailman issues, gmail sucks, I'm working on a fix :)
Cheers !
--
Marc-Olivier Barre
XMPP ID : marco(a)marcochapeau.org
www.MarcOChapeau.org
Hi there,
I'm playing with all the new toys you brought me and have quite some
fun. Just two or three years ago I knew everything out there, now
there are a whole lot of new things to play with.
I have a few questions though.
Is there any new midi sequencer? I know the traditional ones, seq24,
rosegarden, muse, qtractor and so on and briefly tried ardour3 as well
as luppp but could not make heads or tails of it yet. What do you use?
Any idea what happened to the calf stuff? I tried them from git but
the, as far as I remember, wonderful wavetable synth crashes the hosts.
There seems to be a fork of the calf instruments and plugins by falktx
but the wavetable synth and the GUIs seem to be missing.
My goal at the moment is to create a single, simple and probably quite
horrible song electronic music song. That's why I'm looking for a nice
sequencer and some instruments.
Regards,
Philipp
On Mon, Sep 1, 2014 at 3:28 PM, Philipp Überbacher <murks(a)tuxfamily.org> wrote:
> I guess this packaging trick would work, but for some reason I really
> don't like it.
Well... it is the best way to have NSM-supporting programs announce
that they support NSM, but also gives an opportunity to say "use this
icon file for display in the NSM UI", and various other tweaks...
> An alternative idea: NSM could ship with a list of programs that are
> supported, including the information since which version nsm is
> supported. It could then check the installed version and I guess the
> tricky part is to do that reliably.
Not good: parsing output of programs to identify NSM is a
horrible, tedious and error prone "solution"... or "not solution".
> Another idea: NSM could keep a list of nsm-capable programs that were
> started on this particular machine. Once you started zynaddsubfx
> through nsm it will show up on the list.
Possible, installing a new machine, or users who are just starting won't
know what programs support it: as you mention about discovery.
I feel strongly that the solution here should instantly make it easy
for any application to announce its NSM capability, and that no
user interaction should take place (as begining users won't know that).
> Finally just having bash completion would be helpful.
I've not yet coded that type of functionality: but I presume some
regex search on the contents of $PATH is sufficient. Perhaps there's
a library for such out there.
> Actually jackconnect already does something similar, just the other way
> round. NSM waits for a certain period until all clients are loaded and
> sent ready. If some clients are not fast enough or ports are not there
> it still says that the session has been established and after that
> happened jackconnect starts to connect the ports that are there and
> ignores the ones that are not there.
Actually JackPatch just scan's the JACK graph when new ports arrive,
and attaches them if it "knows" about them in the save-file. There is
no delayed loading and such AFAIK.
> Doing something similar is probably not hard, a jackstart client would
> need to figure out when jack was successfully started (not sure how
> hard that is) and signal nsm to start all other clients.
Yep: it doesn't need to explicitly be "JACK started" as such, just a
"pre-startup" command, that announces "OK" when its done its
setup-job. It can continue to run, and have different / related
functionality then.
> A more generic client that could do the same thing for other clients could be useful,
> but I guess not necessary unless someone actually comes up with a need
> for it.
I program as concise and generic as possible:
when somebody does find a use, it will already be supported.
Cheers, -Harry
Hello all.
I hope this isn't too rambling a post to get some replies...
I have seen on this list multiple times lately (possibly by the same person, but never corrected) a statement similar to thus:
"I chose an i5 over an i7 as the i5 doesn't have Hyperthreading whereas the i7 does."
I always thought I remembered this as wrong, especially as I believed I was running a 2 core i5 in my laptop and it shows up as 4 cores. I have just confirmed this to be the case. But it is partially correct, so if anybody has been taking this information for recommendation towards a new CPU purchase this appears to be a clearer picture of the situation.
"The quick explanation is that all Core i7 CPUs use Hyper-Threading, so a six-core CPU can handle 12 streams, a four-core can handle eight streams, and a dual-core can handle four streams. Core i5 uses Hyper-Threading to make a dual-core CPU act like a four-core one, but if you have a Core i5 processor with four true cores, it won't have Hyper-Threading. For the time being, Core i5 tops out at handling four streams, using four real cores or two cores with Hyper-Threading."[1]
As I say, Hyperthreading definitely "works" on my i5 and did with 12.04 as well as 14.04. Whether it helps or hinders I have no idea! I do know that the current Hyperthreading technology has nothing, or very little, to do with the Hyperthrading of the old P4 CPUs and most of the comments I read on it when the processors first came out seem to assume they were the same beast. I also know on Doze systems having it enabled on an i7 gave massive performance boosts with audio software, whereas on the old P4 performance was better with HT disabled (at least initially.)
So can anybody point to any conclusive evidence that i-series processors benefit from having HT disabled on a Linux based DAW? Preferably benchmarks on a system installed with HT Enabled and Disabled using a recent kernel and system.
There are also other BIOS settings I would like some recommendation on how to set. Also how much difference does it make it functions are turned on in BIOS and then Disabled later? I would imaging the other way around would cause more difficulties (as maybe the relevant parts of the kernel wouldn't be installed?) but have definitely read recommendations to make sure to set up BIOS first.
The items in question are:
Intel SpeedStep
CPU Management
Intel Hyper-Threading (mentioned above.)
Also: Are there any good resources on setting up an Arch DAW system? I have been reading as much as possible on the Arch Wiki as I can while we have power and internet here (really not much just lately! About 2 hours the whole of today!!)
Some offline documentation would be very useful, so I can read when the internet is down!
http://archaudio.org seems to be dead in the water! Was it superseded?
Plus these couple of articles I found but admit yet to read as been concentrating on the general Wiki.
http://www.linux.com/learn/tutorials/607117-build-a-serious-multimedia-prod…https://wiki.archlinux.org/index.php/Pro_Audio
Anything else you can point me to I would be very thankful. I believe Arch is the next step I wan to take. :)
Also starting to feel a little disenfranchised with XFCE. What are you guys running your Arch DAW with?
Thanks for any pointers. :)
[1] http://www.pcmag.com/article2/0,2817,2404675,00.asp
Anyone know what Carla does when running SFZ's? Does it encapsulate LinuxSynth or something else? At 96 KHz I get a bit of background static all the time with an SFZ, but an SF2 is clear and beautiful. Could it be a problem with the SFZ, or a problem adapting the SFZ to the high sampling rate?
--
Jonathan E. Brickman
Ponderworthy Music | jeb(a)ponderworthy.com<mailto:jeb@ponderworthy.com> | (785)233-9977 | http://ponderworthy.com
Have just read a bit of Lisalo/LisaloQt, front end for calfbox; what is the status of this project? Also, are there usage examples for calfbox I can learn from?
--
Jonathan E. Brickman
Ponderworthy Music | jeb(a)ponderworthy.com<mailto:jeb@ponderworthy.com> | (785)233-9977 | http://ponderworthy.com
Booted live KXStudio 14.04 DVD. Cadence started JACK, pointed uselessly
at the onboard audio. I pointed it at my USB sound card with the same
settings I use normally. Started Zyn. It visibly made sound (Zyn's
indicator), but no sound came out. (I found nothing in Cadence to
connect Zyn to JACK. But then I don't know Cadence.) I ran KMixer and
audio volume was up for the USB card. So I said, Oh, well, guess it
doesn't work with Zyn. (Not the first time I've had problems with Zyn
and JACK, I much prefer Yoshimi.) So I close Zyn. After which Cadence
reports that JACK server is stopped. Restarting JACK or even force
restarting a JACK restart using Cadence gives me no audio devices to
pick from.
KXStudio isn't ready for this user yet, I guess.
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
Hello,
this is my attempt to build a GTK+ (really GTKmm) C++ application to
edit patches on the Roland MKS 70.
Code is on github: https://github.com/tartina/pg800.git
Tarballs and (maybe) RPM packages will come... some day!
Ciao
Guido
On Friday 29 August 2014 03:21:27 Kaza Kore did opine
And Gene did reply:
> > From: gheskett(a)wdtv.com
> > To: linux-audio-user(a)lists.linuxaudio.org
> > Date: Thu, 28 Aug 2014 22:45:41 -0400
> > Subject: Re: [LAU] Successor/replacement for RME HDSP+Multiface?
> >
> > On Thursday 28 August 2014 21:14:48 Kaza Kore did opine
> >
> > And Gene did reply:
> > > > From: gheskett(a)wdtv.com
> > > > To: linux-audio-user(a)lists.linuxaudio.org
> > > > Date: Thu, 28 Aug 2014 20:37:53 -0400
> > > > Subject: Re: [LAU] Successor/replacement for RME HDSP+Multiface?
> > > >
> > > >...Hi-8 tape...
> > >
> > > I thought we were talking about the future here! The 80s wants its
> > > property back!!
> > >
> > > Also Hi8 is an analogue format so everything in the post is plain
> > > bollocks! Maybe you meant Digital8?? Still 15 years old and any
> > > tape format is pretty much dead and definitely not the future!
> >
> > Not this one, it uses metal tape in the same casette as a Hi-8 would
> > use, but about a tenner more expensive. and is "digital Hi-8"
> > format.
> >
> > Reasonably sharp too at 720p. Go look it up, its a Sony HandyCam
> > DCR- TRV460 NTSC. and about 11 years old IIRC.
>
> So not Hi8 then! :p (If you look I did mention Digital8 too.) Not sure
> where you get the idea it's 720P capable! Specs on website state
> 640x480 and you even state in the name you provided it's NTSC, which
> is never 720P, same as PAL and SECAM aren't. They are old, SD
> standards. 720/1080 P/I are very different beasts really.
>
> Anyway it's probably more important to talk about the standardised DV25
> and DV50 protocol all these commercial/prosumer products use for
> communication that tape/card formats. There are some Sony and
> Panasonic camera that do this fine over USB so it's not impossible or
> a problem with USB itself. I see yours (and apparently many others)
> claim to have some kind of USB Streaming but for some reason it's not
> usually full quality, as you would get from Firewire. Wonder why...
The std says the speed is there. But on this Asus M2N-SLI Deluxe
motherboard that cost $287 USD when I bought it, all USB ports claim to be
USB2.0. The throughput to/from a hard drive in a self powered usb box
that I have 2 of, one 40Gb, one 300Gb drive, has a hard time out running a
floppy disk. No mistakes ever, but the usable bandwidth simply is not
there. My next door neighbor bought one of the 40's the same day I bought
mine, runs it as a backup on her windows machines. On her windows boxes,
it has no problem moving data in either direction at about 50 megabytes a
second.
A 640x480 USB2.0 camera, plugged into the rear port of a D525MW Atom
powered board, only make 3 frames a second.
The linux version of USB is a 1 legged dog in comparison. Why we put up
with that poor usb performance is beyond me. We had the original USB in
full usage on linux a good year ahead of the Redmond version, but IMSNHO,
linux has been sitting on its butt for at least a decade.
What the bloody hell, a copy of the std reference is well within the
financial reach of both Red Hat and Ubuntu & even SuSe. But I don't see
any improvements in the speeds here, and I am currently running a 3.16.0
kernel on a quad core phenom.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
On Friday 29 August 2014 04:33:43 Simon Wise did opine
And Gene did reply:
> On 29/08/14 15:40, Len Ovens wrote:
> > I don't know that the physical technology matters so much as the OS
> > being hyperthreading aware and treating each pair of cores like one.
> > That is making sure that core 0 does not do anything that takes too
> > long for core 1 to meet it's dead line. I do not know if new Linux
> > kernels do this, older ones did not. They logged that the chip had
> > hyperthreading, but still seemed to treat two threads as two
> > different cores.
> >
> > Certainly, common wisdom has not kept up with tech changes. I would
> > be nice to know more.
>
> Not quite on topic, since this isn't to do with Hyper-threading, but
> certainly the Linux scheduler has been getting much more sophisticated
> in dealing with different kinds of cores ... in ARM it now schedules
> tasks for chips with some smaller cores and some faster ones, keeping
> them busy with suitable sized tasks.
>
> The ARM kernels running the most recent Samsung tablets (with 4 big
> plus 4 little cores) have this GTS in the 3.14 kernels ... it runs all
> 8 cores together assigning tasks appropriate to each, rather than just
> switching between big or little of each pair to save power. Selling
> hardware on that scale certainly brings a budget, and since the kernel
> is GPL it can't be kept in-house.
>
> Seems that 3.14 has also added a deadline-based scheduler that is
> closer to what audio needs from realtime than the extremely low
> latency preemption based on priorities that the two older realtime
> schedulers offer.
>
> http://www.linuxfoundation.org/news-media/blogs/browse/2014/01/deadline
> -scheduling-314
>
> Simon
This message is timely as I haven't tried the deadline scheduler in
several years, so I just switched the config to make it the default, and
its building now. Perhaps it will actually improve both the USB lags, and
the network video playback I get here.
Thank you for an informative post.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
