> ----- Original Message -----
> From: Johannes Kroll
>
> On Thu, 17 Jan 2013 12:10:20 +0100
> Johannes Kroll <jkroll(a)lavabit.com> wrote:
>
> > But I'm pretty sure that syncing Phasex to an external MIDI clock
> > worked before, now it doesn't. I'm sending MIDI Clock from Renoise to
> > Phasex. I checked that the ports are connected and the clock is sent
> > with qjackctl & aseqdump. Is it possible that some change between 0.96
> > and 0.97 created a problem with the MIDI Clock?
>
> By "problem" I mean that I remember the BPM value being updated by the
> MIDI Clock, now it isn't.
> I don't know if it's related, but the "Lock parameter (manual
> adjustment only)" checkbox in the "Map MIDI Controller" window of the
> BPM Pot is always checked after phasex startup. I tried turning it off,
> then saving a session. After reloading the session, the "Lock
> parameter" field has always the same value as before, it's apparently
> not affected by session loading. But it is affected by "Load MIDI map".
>
> Turning "Lock parameter" off however doesn't cause the BPM to be
> changed by the MIDI clock, so now I think I might have imagined it was
> doing that in 0.14.96... :-]
(I should have read this before responding to the first email...)
I just found a new issue with the BPM locking with v0.14.97, so I'm not
surprised at all if updating BPM from tempo sync got broken as well.
Getting this fixed will be a priority for v0.14.98.
Cheers,
--ww
> ----- Original Message -----
> From: Johannes Kroll
> On Thu, 10 Jan 2013 22:26:15 -0500
> "William Weston" <whw(a)linuxmail.org> wrote:
>
> > > ----- Original Message -----
> > > From: Johannes Kroll
> > >
> > > I played around with it, it's fun! GUI looks very cool, too.
> > >
> > > After using it a few times, I noticed that some folders with strange
> > > names had been created with files like patchbank, phasex.cfg,
> > > phasex.map, sessionbank in them. The folder names contain weird
> > > characters, Thunar file manager displays them as 'invalid encoding'.
> > > One such folder showed up in my downloads folder, the other one in a
> > > src directory I was working in, possibly the PWDs when I started
> > > phasex... Has anybody else seen this behaviour?
> > >
> > > I'm running Ubuntu 12.04 on x86-64.
> >
> > These files and directories are created when a session is saved via
> > LASH, JACK Session, or native session management. Â I've seen this
> > behavior once before, when first working on LASH support, and it
> > turned out to be a character encoding problem with LASH supplied
> > directory names. Â The only thing I can think of here is to use the
> > "C" locale instead of obtaining locale from the user's environment,
> > so I've made this change in v0.14.97-dev. Â Could you try the latest
> > in git, and let me know how it goes?
>
> I'm not using LASH, but I did save sessions in Phasex "natively". I
> tried the latest git and I don't see the strange directories in the
> working directory where I started Phasex. I don't know if they popped
> up somewhere else, but I think they were in the WD, so I guess that
> fixed it!
Great!
> But I'm pretty sure that syncing Phasex to an external MIDI clock
> worked before, now it doesn't. I'm sending MIDI Clock from Renoise to
> Phasex. I checked that the ports are connected and the clock is sent
> with qjackctl & aseqdump. Is it possible that some change between 0.96
> and 0.97 created a problem with the MIDI Clock?
Are there any specific sync/timing issues that you're trying to solve
by sending MIDI Clock messages?
MIDI Clock messages are currently ignored. Â The original MIDI enabled
version of phasex had this, but it ended up adding too much jitter to
the LFO frequencies and caused more problems than it solved. Â The
internal MIDI clock in phasex is used for timestamping incoming events
and assigning frame position. Â (Future plans include a more robust
tempo clock that can be used with MIDI Clock, MTC, MIDI triggers, tap
tempo, JACK Transport, etc.)
For now, the best options for keeping in sync with tempo changes are
JACK Transport Tempo sync or automating the BPM parameter. Â Not ideal,
I know... but this is better than nothing and should hold up until I
can get the tempo clock designed.
Cheers,
--ww
Artists of the Universal Music Group likely are members of the GEMA, even
if they aren't Germans.
If they catch you when smoking weed in Germany, the sentence isn't very
hard, but if they catch you playing copyright music of GEMA members you
are done. Some countries completely don't care about copyrights , but they
kill you if you're smoking weed. When in Rome, do as the Romans do!
--
No good deed ever goes unpunished.
Einer guten Tat folgt die Strafe auf dem Fuße!
Radium Compressor is the system compressor in Radium,
but distributed as a standalone jack application.
Radium Compressor uses the stereo compressor found in
effect.lib in the Faust distribution.
This compressor is written by Julius O. Smith III.
The GUI shows accurately the sound used for compression,
and how much the sound is being compressed.
I haven't seen this in any audio compressor GUI before,
but it's probably been done before.
Demonstration video: http://www.youtube.com/watch?v=KphCxloBq2w
Tar-ball: http://archive.notam02.no/arkiv/src/?C=M;O=D
Source repository: https://github.com/kmatheussen/radium_compressor
Hello!
We are working on porting CAPS to LV2 and we've just pushed the 0.9.7
version to github. you can check it at:
http://github.com/portalmod/caps-lv2/
We simply modified some basic files, so it's easy to keep in track
with upstream changes. For more info about the port you can read the
PORT section of the README.md file.
Any bugs or troubles regarding the lv2 port please send to this
mailing lists or to the repository issue tracker.
Hope you enjoy :)
On Wed, Jan 16, 2013 at 9:14 AM, Tim Goetze <tim(a)quitte.de> wrote:
> This release of CAPS, likely to be the last for some time unless major
> bugs surface, brings
>
> * performance and sound improvements for AmpVTS,
> * selection of peak or RMS measurement in Compress,
> * 4x128 saturating mode for Compress,
> * 2x,4x and 8x oversampling for AutoFilter, and
> * more filter types for AutoFilter.
>
> The bug in 0.9.4 that rendered the AmpVTS tonestack selection control
> inoperative has been rectified.
>
> Probably appreciated only by its author or other digital
> palaeontologists, the CabinetIII plugin has been reintroduced.
> CabinetIV is still recommended over it because of the wider range of
> models, sample rate independency and lesser computational demands.
>
> Sample rate dependencies have been removed from NoiseGate, and its
> attack time is now configurable.
>
> http://quitte.de/dsp/caps.html
>
> http://quitte.de/dsp/caps.html#AmpVTS
> http://quitte.de/dsp/caps.html#Compress
> http://quitte.de/dsp/caps.html#AutoFilter
> http://quitte.de/dsp/caps.html#NoiseGate
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
Bruno Gola <brunogola(a)gmail.com>
http://bgo.la/ | +55 11 9-5552-3599
This release of CAPS, likely to be the last for some time unless major
bugs surface, brings
* performance and sound improvements for AmpVTS,
* selection of peak or RMS measurement in Compress,
* 4x128 saturating mode for Compress,
* 2x,4x and 8x oversampling for AutoFilter, and
* more filter types for AutoFilter.
The bug in 0.9.4 that rendered the AmpVTS tonestack selection control
inoperative has been rectified.
Probably appreciated only by its author or other digital
palaeontologists, the CabinetIII plugin has been reintroduced.
CabinetIV is still recommended over it because of the wider range of
models, sample rate independency and lesser computational demands.
Sample rate dependencies have been removed from NoiseGate, and its
attack time is now configurable.
http://quitte.de/dsp/caps.htmlhttp://quitte.de/dsp/caps.html#AmpVTShttp://quitte.de/dsp/caps.html#Compresshttp://quitte.de/dsp/caps.html#AutoFilterhttp://quitte.de/dsp/caps.html#NoiseGate
> ----- Original Message -----
> From: Johannes Kroll
>
> I played around with it, it's fun! GUI looks very cool, too.
>
> After using it a few times, I noticed that some folders with strange
> names had been created with files like patchbank, phasex.cfg,
> phasex.map, sessionbank in them. The folder names contain weird
> characters, Thunar file manager displays them as 'invalid encoding'.
> One such folder showed up in my downloads folder, the other one in a
> src directory I was working in, possibly the PWDs when I started
> phasex... Has anybody else seen this behaviour?
>
> I'm running Ubuntu 12.04 on x86-64.
These files and directories are created when a session is saved via
LASH, JACK Session, or native session management. Â I've seen this
behavior once before, when first working on LASH support, and it
turned out to be a character encoding problem with LASH supplied
directory names. Â The only thing I can think of here is to use the
"C" locale instead of obtaining locale from the user's environment,
so I've made this change in v0.14.97-dev. Â Could you try the latest
in git, and let me know how it goes?
Thanks,
--ww
On Thu, 17 Jan 2013 15:10:39 +0100, Tim Goetze <tim(a)quitte.de> wrote:
> [Dave Phillips]
>> From the owner's manual: cE indicates a checksum error.
>>
>> Would that be an error on the part of simplesysexxer or the hardware ?
>
> I seem to remember some piece of MIDI equipment reporting a checksum
> error when I was sending sysex bulks too quickly. After increasing
> the interval between blocks everything was fine. (No idea what
> device it was, certainly not a Yamaha mixer though.)
IIRC for my Yamaha DX7 and the C64 software I've written, it was an issue,
when naming a sound with a special Japanese ASCII sign. AFAIR it was only
the combination of one sound + a special name including this sign, not an
issue when using this sign for other sounds. Voodoo ;). The old (first)
DX7 itself only provided capital letters, numbers and the dot, perhaps a
few additional signs, my sound bank manager enabled usage of other ASCII
signs.
--
FreeBSD 9.1-RELEASE amd64
Greetings,
The subject says it all. I recently had a tech replace the batteries in
two Yamaha DPM11 mixers. As expected, all presets were lost, but I was
able to restore them by a direct sysex transmission from one unit to the
other (before that one's battery replacement). Alas, the transmitted
data doesn't "keep", i.e. when the machine is turned off the battery
appears to be draining its charge, because the presets are gone when I
power up again. Grrrr.
Also, simplesysexxer seems to receive and transmit a bulk dump with no
problems, but the units do not respond correctly. The first preset gets
copied, then I receive an error code "cE". I could make good use of the
machine's error code definitions now, but the only service manual I
found available on the net is from a private dealer who wants too much
money for it. I'll try contacting a retired Yamaha tech in Toledo OH,
but does anyone on these lists have an idea what I should do ? Btw, the
units work fine now, they just don't keep their presets.
Any & all assistance greatly appreciated !
Best,
dp
