My apologies, iOS mail doesn't provide mailing list replies and I tend to forget this.
> On 17 Jan 2017, at 09:40, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
>
>
>
>> On 16 Jan 2017, at 22:16, Jostein Chr. Andersen <jostein(a)vivaldi.net> wrote:
>>
>> On måndag 16 januari 2017 kl. 19:52:43 CET Fons Adriaensen wrote:
>>
>>
>>> I switched to Opera, having lost all trust in Chrome.
>>
>> It's starting to be OT, but:
>>
>> https://vivaldi.com :-)
>
> Oops, I didn't notice, that somebody replied earlier than I did.
Hello,
just been fighting with some jackd starting problems, and figured out that:
jackd --clocksource hpet <snip> produces an:
Unknown option character
error and fails to start, while the short option works:
jackd -c hpet <snip>
JACK compiled with System V SHM support.
loading driver ..
apparent rate = 41000
creating alsa driver ...
hw:HAMMERFALL|hw:HAMMERFALL|1024|2|41000|0|0|nomon|swmeter|-|32bit
configuring for 41000Hz, period = 1024 frames (25.0 ms), buffer = 2 periods
.....
So nothing dramatic here, but if this happens not to be an arch linux
specific issue, maybe the manual page can be fixed with 0.126 or
whatever verion will follow.
Just felt like metioning it and maybe somebody can confirm this
behaviour. Or not.
I feel like there's different types of music production. For instance,
I think recording a live Jazz band is different than working with a
soundtracker clone.
I believe this distinction may be important because people have a broad
set of ideas of what kind of music they'd like to do and it may be
appropriate to divide the tools into different "camps". The camps aren't
mutually exclusive.
The three camps I'm tentative thinking of are
1. microphone recorded
2. synthetically orchestrated
3. experimental
To further build this rational, many times when trying music software I
think "clearly this is a well-thought out piece of software. I just must
not know what I'm doing. Let me toil some more" only to conclude after
many weeks that it wasn't designed to do what I'm looking for but
instead does something adjacent to it. Alternatively, one could argue
this was a false impression I hastily concluded and in fact I dismissed
a potentially great tool because I didn't give it enough time to learn.
Has anyone else thought about this?
I saw an interesting keyboard mentioned in a u-he manual. Soon found that
a ROLI staff member, Filipe Tonello, has their Seaboard Rise 25 working
via BluTooth. See the video on his blog: https://blog.felipetonello.com/
The board has USB B connection as well as BT, so I'm using that.
I use Linux Mint 18 and I've been installing recent kernels to try to get
mine* working. Cinnamon crashes with 4.9 and 4.9.2 kernels, but the kernel
messages in /var/log/syslog showed nothing different with those than with
the supplied 4.4 kernel and a 4.8 one which works without crashing cinnamon:
Kernel 4.4.0-57-generic
Jan 13 14:49:49 Mint-18 kernel: [ 56.286006] usb 1-1.4: new full-speed USB device number 3 using ehci-pci
Jan 13 14:49:49 Mint-18 kernel: [ 56.378889] usb 1-1.4: New USB device found, idVendor=2af4, idProduct=0200
Jan 13 14:49:49 Mint-18 kernel: [ 56.378891] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jan 13 14:49:49 Mint-18 kernel: [ 56.378893] usb 1-1.4: Product: Seaboard RISE
Jan 13 14:49:49 Mint-18 kernel: [ 56.378894] usb 1-1.4: Manufacturer: ROLI Ltd.
Jan 13 14:49:49 Mint-18 mtp-probe: checking bus 1, device 3: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4"
Jan 13 14:49:49 Mint-18 mtp-probe: bus: 1, device: 3 was not an MTP device
Jan 13 14:49:49 Mint-18 kernel: [ 56.393102] usbcore: registered new interface driver snd-usb-audio
Jan 13 14:49:49 Mint-18 systemd-udevd[2177]: Process '/usr/sbin/alsactl -E HOME=/run/alsa restore 1' failed with exit code 99.
Jan 13 14:49:49 Mint-18 pulseaudio[1795]: [pulseaudio] module-alsa-card.c: Failed to find a working profile.
Jan 13 14:49:49 Mint-18 pulseaudio[1795]: [pulseaudio] module.c: Failed to load module "module-alsa-card" (argument: "device_id="1" name="usb-ROLI_Ltd._Seaboard_RISE-00" card_name="alsa_card.usb-ROLI_Ltd._Seaboard_RISE-00" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes card_properties="module-udev-detect.discovered=1""): initialization failed.
So I tried updating ALSA with a 'daily build' snapshot from:
https://code.launchpad.net/~ubuntu-audio-dev/+archive/ubuntu/alsa-daily/+pa…
It won't install for any other than the usual 4.4 kernel and I see no change
in syslog, so I'm stumped. Is it worth trying with BlueTooth? I don't think so.
Will I need to contact Mr Tonello?
* Ordered yesterday, delivered today. Thanks to Amazon.
Also; I used to know how to search this list, but can't seem to find a
searchable archive any more.
--
John.
Chris, aren't you subscribed to the users list? Your messages aren't visible there.
Sounds like we're similar here. If you believe you can pursuade the developer community to adopt your standard, than that's great.
That's one of my indirect questions...
BTW: it's everything but mine standard;-) The schema.org metadata is widely used, supported from all major search engines and under the hood of the w3c consortium.
I'm a far more jaded person and presume nobody would care at all if I tried to do this.
To be honest perhaps some existing ontology system could just be used. There's a few with web interfaces.
Let me look.
If there's something easier, let me know.
Holger
On Jan 13, 2017 06:00, holger(a)dehnhardt.org (mailto:holger@dehnhardt.org) wrote:
Hmm, my english skills leave me here;-) A kind of ontology is what I was aiming too. Not a date but data - in the sense of "information".
Did you get me wrong here or do I get you wrong...
Things like "audioInterfaceType" (jack, alsa...) and "audioPluginInterfaceType" (lv2, ladspa...) as well as applicationCategory (DAW, Effekt, Notation...) and all we find important would be extractable and searchable. (And Google and other search engines might make things more searchable as well...)
Holger
13. Januar 2017 14:40 Uhr, "Chris McKenzie" schrieb:
Also this is all arguably just props up anb insufficient solution.For me at least, the only reason I care about the date is that it's the best *indirect* indicator of whether something say, works with jack or lv2 or what have you.An ontology that would be far more useful than the indirect reporting of a date would be to (and some of this is done on the site)list the types of inputs (midi, jack, etc) and outputs of a programWhether they are meant for low latency "live" performances or notList what kind of plugin standards the thing works withInclude, if possible, similar programs that may be more difficult or less difficult to learn, for people of various dedication and skill.The "ontology" part of this is important because ideally there could be a "web app" where you could string your stack together of different applications.These could also be used for demonstration purposes to help other people understand the various ways things can fit together.Because in practice, at least I have spent a lot of time in trying to learn what some software is good at, what it does for me, and how I could possibly connect it with everything else.These things are relatively simple to communicate but currently as far as I know, isn't happening.
On Jan 13, 2017 5:19 AM, Chris McKenzie wrote:
Interesting idea. There's potentially a far quicker execution of it that doesn't need a buy in from everyone.You take all the repo links for the projects and then have a script that pulls them say twice a month. Then with a little git or svn magic you can find out if a newer release has been tagged and when it came out.Also you can piggy back on apt repos for other thingsapt-cache show XxxGenerally has a pretty good description if the wiki is lacking along with an up to date website.So I'm pretty sure some basic parts can be readily scripted within a few hours. There's various models I can think of so the autopopulation is useful and there when you need it but doesn't necessarily clobber human created content.
Hmm, my english skills leave me here;-) A kind of ontology is what I was aiming too. Not a date but data - in the sense of "information".
Did you get me wrong here or do I get you wrong...
Things like "audioInterfaceType" (jack, alsa...) and "audioPluginInterfaceType" (lv2, ladspa...) as well as applicationCategory (DAW, Effekt, Notation...) and all we find important would be extractable and searchable. (And Google and other search engines might make things more searchable as well...)
Holger
13. Januar 2017 14:40 Uhr, "Chris McKenzie" schrieb:
Also this is all arguably just props up anb insufficient solution.For me at least, the only reason I care about the date is that it's the best *indirect* indicator of whether something say, works with jack or lv2 or what have you.An ontology that would be far more useful than the indirect reporting of a date would be to (and some of this is done on the site)list the types of inputs (midi, jack, etc) and outputs of a programWhether they are meant for low latency "live" performances or notList what kind of plugin standards the thing works withInclude, if possible, similar programs that may be more difficult or less difficult to learn, for people of various dedication and skill.The "ontology" part of this is important because ideally there could be a "web app" where you could string your stack together of different applications.These could also be used for demonstration purposes to help other people understand the various ways things can fit together.Because in practice, at least I have spent a lot of time in trying to learn what some software is good at, what it does for me, and how I could possibly connect it with everything else.These things are relatively simple to communicate but currently as far as I know, isn't happening.
On Jan 13, 2017 5:19 AM, Chris McKenzie wrote:
Interesting idea. There's potentially a far quicker execution of it that doesn't need a buy in from everyone.You take all the repo links for the projects and then have a script that pulls them say twice a month. Then with a little git or svn magic you can find out if a newer release has been tagged and when it came out.Also you can piggy back on apt repos for other thingsapt-cache show XxxGenerally has a pretty good description if the wiki is lacking along with an up to date website.So I'm pretty sure some basic parts can be readily scripted within a few hours. There's various models I can think of so the autopopulation is useful and there when you need it but doesn't necessarily clobber human created content.
Several times I was looking for a list of audio applications on Linux, when I was searching for a
program or tool that is able to do something special.
There is a list in the linuxaudio.org wiki, but it often is outdated. I had an idea to resolve this
problem and was trying some things the last days. Now that Chris McKenzie wrote on the developer
list that he is about updating this list and is asking a question what catogories might be useful,
I would like to share my thoughts with you (I hope the developers are on this list too).
Have you ever heard about schema.org (www.schema.org)? They are developing schemas for meta data
inside websites. There is an set of classes and properties for software applications but it is not
detailed enough for this purpose but: it is extendable.
My idea is, that every devloper tags the site where his application / effect / tool is presented
with appropriate tags. register their site within an collector and we collect this meta data daily and create an dynamic list out of this.
Every time a developer updates his site this information will be collected automatically and the
software list is nearly up to date. (Maybe one day behind the updates)
I have set up an example page with some structured data. You can see the contained data when you
open https://search.google.com/structured-data/testing-tool
and use https://www.dehnhardt.org as the url to test. (Rui, I hope you dont'n mind I took a
screenshot from QTractor...)
You can see two panels there: In the left the html with the meta-tags and on the right you see what
data can be extracted. Don't worry abot the unknown type as it is what I extended to the schema)
What do you think about this idea? If you like it, I would like to debate the structure of the meta data here before writing an proposal for schema.org. I'm willing to write the aggregator for the meta data as well.
Holger
For those looking for high bit rate, non-usb, stable multi-channel input
and output on the pi (6 in 8 out), this current Kickstarter may be of
interest. I'm not affiliated with the guy responsible for this , but I do
have his first board, the 2 in 2 out version. So far it seems very stable
at reasonably low latency settings in JACK and has the added benefit of
mainline kernel support. If the multi-channel version works nearly as well
it may be a winner.
https://www.kickstarter.com/projects/1250664710/audio-injector-octo-surroun…
Hi,
in this German document [1] Sengpil [2] added a note for
balanced out ---> unbalanced in
for electronically balanced out without galvanic isolation to ground. He
mentioned to connect the + signal _and_ ground (not _with_ ground,
just to prevent against a misunderstanding), but the - signal should be
unconnected.
IOW
balanced out + -------------> unbalanced in
- NC
0 ------------->
There's a lot of chaotic half-truth about this topic in forums.
Considering this document, it makes sense why not all
balanced <--> unbalanced connections require the same kind of cable and
especially why I didn't notice an issue for balanced <--> unbalanced
connections before I got the Focusrite. However, the headphone amps of
the Focusrite are still crap and apart from connecting the Focusrite
blanced ---> balanced to itself, I even didn't ensure that the
balanced ---> unbalanced issue mentioned by Fons is the culprit, but it
could be the reason for the bad sound.
It might be useful for others, too.
[1] http://www.sengpielaudio.com/Geraeteverbindungen.pdf
[2] http://www.sengpielaudio.com/Searchengine.htm
Regards,
Ralf
