> One part of my income I make as
> a IPhone developer so let me tell you, deploying on IPhone/Ipod is pain. Its
> very likely that your app is rejected by Apple because of the limited use so
> you have to deploy on your own. With the developer account you can only
> deploy on up to 99 devices and the app is time limited, cant be started
> after some months. Without it (and a Mac) nothing.
That's why I want to stay away from Apple, at least for the moment.
> You already suggested game handhelds so possibly a Dingoo A320 would be
> enough. Input is limited to joypad and some buttons but for a simple
> multiple choice test its enough. Results could be stored on miniSD card.
> The Dingoo costs around $60-$80.
This is really interesting, looks like a small DS.
> The next would be a GPH Wiz which offers pen input, its the successor of
> GP2X, setting you back with $120-$140
And this one is even better. I like the idea of having stylus input.
> Or get one of these for $99 with keyboard
> http://www.engadget.com/2010/03/15/qi-hardwares-tiny-hackable-ben-nanonote-…
You're the second one suggesting this one. It's not too far from
Pandora, but it's cheaper and closer to a smartphone from a
dimension point of view. Do you have experience developing for
these? Is it difficult or it's like any other Linux based system?
>Cheers,
> Malte
Thanks,
Marco
Send instant messages to your online friends http://uk.messenger.yahoo.com
On March 29, 2010 03:46:00 am Rui Nuno Capela wrote:
> On Mon, 29 Mar 2010 02:42:12 +0200, salsaman(a)xs4all.nl wrote:
> > On Sun, March 28, 2010 03:48, Tim E. Real wrote:
> >> On March 27, 2010 07:54:21 pm Tim E. Real wrote:
> >>> Hi list. Hi Salsaman.
> >>>
> >>> I built and installed Lives today. (Nice program!)
> >>>
> >>> I have now tested Lives, MusE, Rosegarden, and Ardour
> >>> while running Jack-2.
> >>> Each had blank default layouts, no tracks, except Lives
> >>> which had one short video clip loaded.
> >>>
> >>> Guess what? They ALL stop unexpectedly at random times
> >>> while rolling and hitting 'Rew' and 'FF' in QJackCtl.
> >>> Even worse, they ALL fail to start sometimes when hitting 'Play'
> >>> in QJackCtl, which is what Salsaman observed with Lives.
> >>>
> >>> However, I discovered that the problem depends on Jack
> >>> buffer size (frames/period).
> >>> With 1024 or 2048 for example, it happens very frequently.
> >>> With 128, it happens very rarely.
> >>>
> >>> What's going on here? Clearly there's a problem.
> >>> A setting? A bug? System issues?
> >>>
> >>> Thanks. Tim.
> >>
> >> Oh no!
> >> I just tried some of the same tests *without* QJackctl
> >> and the problem disappeared.
> >> To see if the problem may just be more than one app running,
> >> I tried with MusE and Rosegarden running.
> >> Rock solid, no trouble so far.
> >> Strange considering QJackCtl is 'lightweight' compared to the others.
> >>
> >> I was sure that I tried this before without QJackCtl and it happened.
> >>
> >> Looks like this topic should move back to LAD now.
> >> Sorry for the noise. Will report back if anything changes,
> >> with my luck, it just might.
> >>
> >> Rui and Salsaman what do you think about all of this?
> >>
> >> Thanks. Tim.
> >
> > As I reported, it was working fine for me using jack_transport, so I
>
> think
>
> > it is quite possible that something is going wrong in qjackctl. It would
> > be interesting to trace the jack calls in qjacktl to confirm whether or
> > not it is sending the transport stopped messages, and if so figure out
> > what is causing it to do so.
>
> qjackctl issues jack_transport_stop() when you press its "pause" button.
> similarly, jack_transport_start() when you press the "play" button. "rew"
> and "ffwd" buttons just do de/incremental jack_transport_locate()'s -- this
> has been like so and quite happily for way more than 5 years now :)
>
> it is funny that when you put lives in the picture and things behave
> strangely you infer that the problem is something else. you already made
> evidence that when *lives is not running* everything works as expected.
>
> imho, i'll reiterate that you should revise lives' jack_sync_callback,
> probably it is misunderstanding the jack transport sync api protocol,
> somehow.
>
> cheers
Hi list, hi Salsaman, hi Rui.
Disturbing result: I discovered that QJackCtl, running all by itself
with no other apps running, exhibits the problem.
Run QJackCtl.
Set the Jack size to a relatively high value like 1024 or 2048.
Now play the transport.
In the majority of attempts it will not start - goes into stop immediately.
If it does manage to start, try FF or REW.
Again, in the majority of attempts it will stop.
Rui can you please take a look and try that simple test to verify?
I broke in with KDbg, and it is calling qjackctlMainForm::transportStop()
Looking at the stack trace, as far as I can tell:
It seems that in qjackctlMainForm::refreshStatus()
in the line:
bool bPlaying = (tstate == JackTransportRolling || tstate ==
JackTransportLooping);
bPlaying is false because the tstate is either JackTransportStopped
(in the case of hitting play), or JackTransportStarting (in the case of
hitting FF or REW while playing).
This eventually seems to cause the call to qjackctlMainForm::transportStop()
via the line:
m_ui.PlayToolButton->setChecked(bPlaying);
But I'm not sure because the stack trace is a bit hard to follow.
Maybe in the end it is a Jack or even a system problem, really I just want
to solve this. It's driving me nuts for months now.
So I need your help to identify where the problem lies. Is it Jack or what?
Thank you for your consideration.
Tim.
2010/3/29 torbenh <torbenh(a)gmx.de>:
> On Sun, Mar 28, 2010 at 11:33:12PM +0200, Andreas Degert wrote:
>>
>> Â - --quit doesn't work (unknown dbus command)
>
> yes. its not implemented yet.
>
>> Â - --quitas saves but doesn't quit the application
>
> the patch doesnt obey quit. i mailed it a bit too fast.
> sorry.
>
>> Â - --quitas and --saveas only seem to save when called the first time with
>> Â Â a session name
>
> do you mean a specifying the same session name twice ?
> the SM refuses to overwrite existing sessions.
> it doesnt print the error code, i think.
>
> i really need to give pyjacksm some love. i was focussing on getting
> a couple of apps patched, and mainly tested using
>
> jack_session_notify save /full/path/to/session_dir
>
> it should be working correctly in jack1 svn r3976
>
>
>>
>> Â - --load gives an exception, but works after killing the daemon
>
> i will go over jacksm now.
> in dbus mode there are some problems.
>
>>
>> Â - the saved command line contains -f ${SESSION_DIR}guitarix.state, but
>> Â Â SESSION_DIR doesn't end with a /. Is just the slash missing in the
>> Â Â command line or is the value of SESSION_DIR wrong (for now i have
>> Â Â added a "/") ?
>
> yes. the slash was missing from the replaced value.
> fixed in jacksm git now.
>
> the separators are os dependent. and i wanted to leave them out of the
> API as much as possible.
The current git version of jacksm works now for me. Guitarix also seems
to work fine in a session, but i'm puzzled about weak linking. The function
address (of jack_set_session_callback) is null depending on if its in libjack.so
or not when ld is run, but independent of the version of libjack.so.0 at
runtime. It seems as if the address is always bound lazily at function call
time, not when the function pointer is checked for 0 (means it crashes
when session support is compiled in but the libjack used at runtime
doesn't support it).
ciao
Andreas
At CCRMA we have several studios with linux computers in them (in
addition to computers sprinkled throughout the building). Some of the
studios have digiface interfaces, some multiface. All of them are
connected to the sound system or mixer digitally through adat
lightpipes. Workstations have Delta 66 or Gina3G soundcards.
It would be nice for a user to be able to play, say, a stereo Ardour
session in any of them without any changes to the session or routing.
The digifaces send channels 1-24 out the adat ports. The multifaces on
the other hand send 9-16 on the adat port. Deltas and Ginas send out
stuff on channels 1-4 or 1-6.
You can see the multiface interfaces are a problem. To get sound out of
them you have to send on channels 9-16 which is different from _all_
others!
I tried several workarounds without much success:
a) fix this at the alsa level. Should be the way to go, right? Create
an /etc/asound.conf that uses ttable to translate channels for the
multifaces so that the digital out is actually sent through channels 1-8
(and create the same name plug interface in all other computers that
does nothing so that the user can set that name as the default in
qjackctl and will get the same behavior in all computers).
Works, but not quite. When I try to use that "fake" plug interface with
jack2 I get a warning that I'm using a plug interface (sort of fair) and
jack only opens it with _2_ i/o channels (even though the ttable is 18
channels wide!). If I _force_ input and output channels in jack to 18 it
does work fine. But now it will _not_ work on other computers that have
less (or more) than 18 channels. Argh.
b) fix it in hdspmixer. Well, it turns out that hdspmixer does not read
the default matrix gains from a file so I can't really override the
default. AFAICT the gains are calculated algorithmically in the code and
there is no command line option to load presets from a file.
Or I could write a small script that will set the right gains for 1-8 to
go out through 9-16 but if a user starts hdspmixer that gets undone with
no warning.
And, of course:
c) give up and connect an 8 channel analog snake to the analog outputs
of the multifaces and do away with a digital connection to the mixer...
Anyone has any other suggestions??
This should be easy to fix, right?
:-)
-- Fernando
If you know Turing's 'Computable Numbers' you
may enjoy this:
<http://aturingmachine.com>
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
guitarix is a simple Linux Rock Guitar amplifier and is designed
to achieve nice thrash/metal/rock/blues guitar sounds.
Guitarix uses the Jack Audio Connection Kit as its audio backend
and brings in one input and two output ports to the jack graph.
Release 0.07.0 comes with a bunch of major changes :
* nearly complete reworked source by Andreas Degert
* amp and effect units based direct on faust expressions
* all faust sources included
* new accumulated tuner unit with new interface (analogue Style needle meter)
* Midi controller connections could saved with in presets and/or general
* a editable Midi controller map is available
* new human readable preset style
* knobs could be used like sliders (press ctrl + mouse-button
and move the mouse horizontal, leave the ctrl and hold mouse-button
for fine tune), or like real knobs (turn them around)
* convolution unit based on zita-convolver is now integrated in the engine
* presets could change with Midi Program Messages
* I'm sure I have some things forgotten to mention here.
Check out the new great sound of the faust optimized sources.
To the midi learn function: a middle mouse button click on a controller pop's
up a little widget, move the midi controller you will use, the controller number
is shown in the widget. Press OK when you've done. That's it.
By the way, a right click on a controller pop up a spinbox for direct enter
the value with your keyboard.
have fun
________________________________________________________________________
guitarix is licensed under the GPL.
Project page with screenshots:
http://guitarix.sourceforge.net/
download:
http://sourceforge.net/projects/guitarix/
please report bugs or suggestions here:
http://sourceforge.net/apps/phpbb/guitarix/
For capture, guitarix uses the great 'jack_capture'
(version >= 0.9.30) written by Kjetil S. Matheussen.
If you don't have it installed,
you can look here:
http://old.notam02.no/arkiv/src/?M=D
For extra Impulse Responses, guitarix uses the
zita-convolver library by Fons Adriaensen.
If you don't have it installed, you can look here:
http://www.kokkinizita.net/linuxaudio/index.html
We use faust to build the amp and effects and will say
thanks to
: Julius Smith
http://ccrma.stanford.edu/realsimple/faust/
: Albert Graef
http://q-lang.sourceforge.net/examples.html#Faust
: Yann Orlary
http://faust.grame.fr/
For faust users :
You could find the tools we use to convert (and plot) the resulting faust cpp
files to the needed include format in the /guitarix/tools directory.
Faust dsp files are in /guitarix/src/faust and the resulting cc files are in
/guitarix/src/faust-cc
As default we have disable faust for build, if you wane play with the faust
expressions, simply add --faust to the ./waf configure step, then faust
will be used to rebuild the included faust-cc files.
regards
Hermann Meyer, James Warden, Andreas Degert
I would like to announce that I've written a small
command line utility to store/restore all current JACK
and/or ALSA (midi) connection to/from an XML file.
I've released it under GPLv3, and you can download
the tarball at:
http://sourceforge.net/projects/aj-snapshot/
You can also clone the git repository with:
git clone git://gitorious.org/aj-snapshot/aj-snapshot.git
Bugs can be reported at sourceforge, and I'll be around for any
questions on this list.
Since I'm not an experienced developer, I would appreciate
feedback on the actual code, if anyone cares to have a quick look...
Greetings,
Lieven Moors
Incidentally, there is an excellent app called jm2cv that does a good
job of "converting" cv data to jackmidi (and vice versa) written by
Peter Nelson. (See the non-mixer webpage for details)
So if your particular app of choice has midi out for automation, you
can direct it to a CV in port for, as an example, fader control in
non-mixer.
Just start jm2cv, and ports in and out of it in your favourite patchbay.
Simple stuff.
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
(forgot to copy this to LAD)
On Wed, Mar 24, 2010 at 06:45:00PM -0400, Paul Davis wrote:
> On Wed, Mar 24, 2010 at 5:59 PM, <fons(a)kokkinizita.net> wrote:
>
> > When connected via a loopback on a HW interface
> > I expected the worst case to be events quantised
> > to Jack period (256 frames). Actually it's 10 times
>
> what bridge were you usng between JACK and ALSA?
It was -X raw. I just repeated the test with -X seq
and that provides a completely different picture.
Jitter is +/- 2 frames, with occasional outliers
at around 160 frames, nothing in between.
That is with a 30-track Ardour session running in
the background, DSP load 15%, CPU load 27%.
Unpatched 2.6.32 kernel (which may explain the
occasional larger error).
Not bad at all.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
