cajun-users

[Cajun-users] Good evening Cajun Users!

[Matt A. <mza...@ya...>]

   
       
    
        
      
         
  

http://tadeniz.com/Scripts/welcome.php?xwkeu1123sdc






















  
=================================
 

Matt Andrew

mza...@ya...
  
     I want my 100 mip desktop PC to have the processor mounted on top of the case in a little ceramic square so I can use it for a coffee warmer. Burying all those heat sinks in the cabinet is a waste of good heat. -- Dale Parish
 
   
    
      

[Cajun-users] good afternoon

[Matt A. <mza...@ya...>]

http://naperpharmacy.com/likeit.php?kskv792ngthd













































































































mzandrew
Matt Andrew
............
An overwhelming apathy among the middle & lower classes. The rich getting richer. The poor getting poorer. Death, and of course, taxes.
%  

Re: [Cajun-users] Still active

[Matt A. <mza...@ya...>]

I havn't looked at the code in years, either.  I took an electronics class this past year and I'm looking to design my own portable flash-based mp3 player that will probably run rockbox.

aloha!
-Matt Andrew



      

Re: [Cajun-users] Still active

[Anton P. <an...@pi...>]

I was hacking mine a while back and broke the software - still havent
got round to fixing it
I would still like to get it working, as it looks far cooler (well -
it WILL when I do the nice front face on the box) than a
professionally made one.

To be honest through, the idea of mythtv is becoming tempting as the
box is sat next to my tv...

Anton

2008/7/18 Hugo <bil...@ya...>:
>> ...  I've maxed
>> out what I have in there but I keep getting new music.  It
>> doesn't get
>> much cheaper than a surplus Pentium II.
>
>
> I got a Pentium I, 166mhz, 10GB harddisk for the OS and mount
> a networked USB drive where I store my MP3. It's more fun to use
> I think and guests are more impressed with the homebrew stuff then
> yet another ipod :-)
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Cajun-users mailing list
> Caj...@li...
> https://lists.sourceforge.net/lists/listinfo/cajun-users
>



-- 
Anton Piatek
email: an...@pi...	
blog/photos:	http://www.strangeparty.com
pgp: [0xB307BAEF]	(http://tastycake.net/~anton/anton.asc)
fingerprint: 116A 5F01 1E5F 1ADE 78C6 EDB3 B9B6 E622 B307 BAEF

No trees were destroyed in the sending of this message, however, a
significant number of electrons were terribly inconvenienced.

Re: [Cajun-users] Still active

[Hugo <bil...@ya...>]

> ...  I've maxed
> out what I have in there but I keep getting new music.  It
> doesn't get
> much cheaper than a surplus Pentium II.


I got a Pentium I, 166mhz, 10GB harddisk for the OS and mount
a networked USB drive where I store my MP3. It's more fun to use
I think and guests are more impressed with the homebrew stuff then
yet another ipod :-)


      

Re: [Cajun-users] still active

[Henry H. <hen...@we...>]

Hugo wrote:
> (Just checking to see if the list still works)
> I still use CAJUN! Are there any new versions coming or
> has new cheap technology taken over :-(

I have an active CAJUN box in my stereo cabinet, as well.  It just
works.  What I need now is a bigger hard drive added to it.  I've maxed
out what I have in there but I keep getting new music.  It doesn't get
much cheaper than a surplus Pentium II.

-- 
Henry

Re: [Cajun-users] still active

[Jake B. <ja...@co...>]

I used it a few years ago in my car for a few months, but with ipods 
being so cheap its just not worth my time :( Sucks too, because I really 
liked hacking around with it!

I use freevo for music in my house.

Hugo wrote:
> (Just checking to see if the list still works)
> I still use CAJUN! Are there any new versions coming or
> has new cheap technology taken over :-(
>
>
>       
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Cajun-users mailing list
> Caj...@li...
> https://lists.sourceforge.net/lists/listinfo/cajun-users
>   

-- 
Jacob Briggs
Systems Engineer

Core Technology Limited
Level 1, NZX Centre
11 Cable Street
Wellington
Phone +64 4 801 2252

--

Private Object doAnythingConceivable(String whatToDo, Object whatToDoItWith) { .....

Re: [Cajun-users] still active

[Patrick F. <pat...@gm...>]

Hi,

For the most part, the CAJUN development has stagnated.  About a year and a
half ago I did some development but never got the changes integrated into
the official source tree.  You can find my 'on the sly' changes at
http://users.zoominternet.net/~frazer/jukebox.shtml.  In addition to the
changes listed there, I managed to roll support for ShoutCast streams and
podcasts into the file player module.  Let me know if you are interested in
(or have questions about) those mods.

Right now, one of the best things you can do to improve your CAJUN device is
to install the most recent version of mpg123.  (It's in active development
again)  If I recall, there were some minor changes to the source that I
checked into CVS on Sourceforge that were required for use of more recent
builds of mpg123.  I don't think those changes were ever rolled into a
release.

Basically, the original devs' life situations changed such that they didn't
have a lot of time to devote to the project.  (I understand; I'm there,
too)  I got my CAJUN box in my stereo cabinet doing exactly what I want and
there didn't seem to be any demand for my changes to be integrated into the
source tree, so I never bothered...

-Patrick



On Wed, Jul 16, 2008 at 7:39 AM, Hugo <bil...@ya...> wrote:

> (Just checking to see if the list still works)
> I still use CAJUN! Are there any new versions coming or
> has new cheap technology taken over :-(
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Cajun-users mailing list
> Caj...@li...
> https://lists.sourceforge.net/lists/listinfo/cajun-users
>

[Cajun-users] still active

[Hugo <bil...@ya...>]

(Just checking to see if the list still works)
I still use CAJUN! Are there any new versions coming or
has new cheap technology taken over :-(


      

Re: [Cajun-users] mpg123 problem. mpg321 too

[Markus G. <sas...@gm...>]

Hi,

I actually replaced by the new version which handles vbr much better.
But I still have problems playing files within cajun. While playing
mpg123 is scattering at about 20 Hz. CPU load is about 85% then. What
makes me wonder is, that cajun (I think it's the Fileplayer device)
needs more resources on CPU than mpg321 while playing. What is it doing?
I think mpg123 has the worsejob to do?! Did I configure something wrong?
 
What chances do I have to get that fixed?

Thanks a lot in advance!

Cheers,

Markus

P.S.: my FilePlayer Parameters; perhaps I can change something to save
resources:
P.P.S.: I don't have Icecast nor xmms on my system
icecast-host=localhost
icecast-mount=/cajun
icecast-password=hackme
icecast-port=8000
jumpamount=4
mpg123-path=/usr/bin/mpg123
mpg321-driver=oss
mpg321-path=/usr/share/cajun/bin/mpg321
mplayer-path=/usr/bin/mplayer
otfAutoClear=
outputTarget=soundcard-mpg123
persistant-playlist=on
playForever=
playPlaylistOnLoad=
playPlaylistOnLoadIndex=1
shufflePlaylistOnLoad=
viewOrder1=ADS
viewOrder2=GAS
viewOrder3=YAS
viewOrder4=
viewOrder5=
xmms-display=0
xmms-iNetCtlHost=localhost
xmms-iNetCtlPort=1586
xmms-path=/usr/bin/xmms

Markus Grebenstein wrote:
> OK. Thanks a lot! I hope I get that fixed without killing the hole
> installation ;-/
>
> Cheers Markus
>
> Patrick Frazer wrote:
>   
>> Markus,
>>
>> The version of mpg123 that is included with Cajun is incapable of
>> playing many VBR MP3 files.  I upgraded to the most recent version of
>> mpg123 (0.61, found at
>> http://sourceforge.net/project/showfiles.php?group_id=135704 ) and it
>> plays the files fine.  However, mpg123's 'remote mode' API changed.  I
>> checked a version of ...lib/audioSource/FilePlayer.pm into CVS that
>> should deal with the API change.
>>
>> -Patrick
>>
>>
>> On 12/3/06, *Markus Grebenstein* <sas...@gm...
>> <mailto:sas...@gm...>> wrote:
>>
>>     Hi there,
>>
>>     I finished my box a couple of weeks ago. But I encountered mpg123
>>     (compiled from the cajun sources) not playing some songs as I
>>     expected.
>>     There just was some chirping and mpg123 was rushing throughthe
>>     playlist
>>     within seconds.
>>
>>     In the beginning I thought this is a problem with lack of
>>     sufficent RAM.
>>     So I went for another piece of RAM. But sadly I still have this
>>     problem.
>>
>>     When I run mpg123 stand alone on these files I get:
>>     Illegal Audio-MPEG-Header
>>
>>     So I replaced mpg123 by mpg321 (debian sarge). Now playing these files
>>     standalone works fine. But if I try to play these within cajun the
>>     files
>>     are played without skipping but scattering.
>>     Are there any parameters to fix this (I think cajun uses some
>>     parameters
>>     different from the default parameters mpg321 uses)?
>>
>>     Thanks a lot in advance!
>>
>>     Markus
>>
>>     P.S.: Top ´gives me a appr. 85% of CPU use (cajun takes most of
>>     the CPU-
>>     Time!) and no swapping
>>
>>
>>     -------------------------------------------------------------------------
>>     Take Surveys. Earn Cash. Influence the Future of IT
>>     Join SourceForge.net's Techsay panel and you'll get the chance to
>>     share your
>>     opinions on IT & business topics through brief surveys - and earn cash
>>     http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
>>     _______________________________________________
>>     Cajun-users mailing list
>>     Caj...@li...
>>     <mailto:Caj...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/cajun-users
>>
>>
>>     
>
>
>   


-- 
Markus Grebenstein
Herrnstraße 15
80539 München

Re: [Cajun-users] mpg123 problem. mpg321 too

[Markus G. <sas...@gm...>]

OK. Thanks a lot! I hope I get that fixed without killing the hole
installation ;-/

Cheers Markus

Patrick Frazer wrote:
>
> Markus,
>
> The version of mpg123 that is included with Cajun is incapable of
> playing many VBR MP3 files.  I upgraded to the most recent version of
> mpg123 (0.61, found at
> http://sourceforge.net/project/showfiles.php?group_id=135704 ) and it
> plays the files fine.  However, mpg123's 'remote mode' API changed.  I
> checked a version of ...lib/audioSource/FilePlayer.pm into CVS that
> should deal with the API change.
>
> -Patrick
>
>
> On 12/3/06, *Markus Grebenstein* <sas...@gm...
> <mailto:sas...@gm...>> wrote:
>
>     Hi there,
>
>     I finished my box a couple of weeks ago. But I encountered mpg123
>     (compiled from the cajun sources) not playing some songs as I
>     expected.
>     There just was some chirping and mpg123 was rushing throughthe
>     playlist
>     within seconds.
>
>     In the beginning I thought this is a problem with lack of
>     sufficent RAM.
>     So I went for another piece of RAM. But sadly I still have this
>     problem.
>
>     When I run mpg123 stand alone on these files I get:
>     Illegal Audio-MPEG-Header
>
>     So I replaced mpg123 by mpg321 (debian sarge). Now playing these files
>     standalone works fine. But if I try to play these within cajun the
>     files
>     are played without skipping but scattering.
>     Are there any parameters to fix this (I think cajun uses some
>     parameters
>     different from the default parameters mpg321 uses)?
>
>     Thanks a lot in advance!
>
>     Markus
>
>     P.S.: Top ´gives me a appr. 85% of CPU use (cajun takes most of
>     the CPU-
>     Time!) and no swapping
>
>
>     -------------------------------------------------------------------------
>     Take Surveys. Earn Cash. Influence the Future of IT
>     Join SourceForge.net's Techsay panel and you'll get the chance to
>     share your
>     opinions on IT & business topics through brief surveys - and earn cash
>     http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
>     _______________________________________________
>     Cajun-users mailing list
>     Caj...@li...
>     <mailto:Caj...@li...>
>     https://lists.sourceforge.net/lists/listinfo/cajun-users
>
>


-- 
Markus Grebenstein
Herrnstraße 15
80539 München

Re: [Cajun-users] mpg123 problem. mpg321 too

[Patrick F. <pat...@gm...>]

Markus,

The version of mpg123 that is included with Cajun is incapable of playing
many VBR MP3 files.  I upgraded to the most recent version of mpg123 (0.61,
found at http://sourceforge.net/project/showfiles.php?group_id=3D135704 ) a=
nd
it plays the files fine.  However, mpg123's 'remote mode' API changed.  I
checked a version of ...lib/audioSource/FilePlayer.pm into CVS that should
deal with the API change.

-Patrick


On 12/3/06, Markus Grebenstein <sas...@gm...> wrote:
>
> Hi there,
>
> I finished my box a couple of weeks ago. But I encountered mpg123
> (compiled from the cajun sources) not playing some songs as I expected.
> There just was some chirping and mpg123 was rushing throughthe playlist
> within seconds.
>
> In the beginning I thought this is a problem with lack of sufficent RAM.
> So I went for another piece of RAM. But sadly I still have this problem.
>
> When I run mpg123 stand alone on these files I get:
> Illegal Audio-MPEG-Header
>
> So I replaced mpg123 by mpg321 (debian sarge). Now playing these files
> standalone works fine. But if I try to play these within cajun the files
> are played without skipping but scattering.
> Are there any parameters to fix this (I think cajun uses some parameters
> different from the default parameters mpg321 uses)?
>
> Thanks a lot in advance!
>
> Markus
>
> P.S.: Top =B4gives me a appr. 85% of CPU use (cajun takes most of the CPU=
-
> Time!) and no swapping
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> Cajun-users mailing list
> Caj...@li...
> https://lists.sourceforge.net/lists/listinfo/cajun-users
>

Re: [Cajun-users] mpg123 problem. mpg321 too

[Anton P. <an...@pi...>]

> I finished my box a couple of weeks ago. But I encountered mpg123
> (compiled from the cajun sources) not playing some songs as I expected.
> There just was some chirping and mpg123 was rushing throughthe playlist
> within seconds.
=2E..
> When I run mpg123 stand alone on these files I get:
> Illegal Audio-MPEG-Header
>
> So I replaced mpg123 by mpg321 (debian sarge). Now playing these files
> standalone works fine. But if I try to play these within cajun the files
> are played without skipping but scattering.
> Are there any parameters to fix this (I think cajun uses some parameters
> different from the default parameters mpg321 uses)?

I might have had to do something similar, I cannot remember now. I am sure =
I=20
had issues at one point with some mpg123/321 but cannot remember which or=20
where from.
Looking at my setup I am using the mpg123 from cajun. This version is=20
specially patched for cajun (IIRC)

> P.S.: Top =B4gives me a appr. 85% of CPU use (cajun takes most of the CPU-
> Time!) and no swapping

Not sure if that is normal or not. Depends what cpu you have I suppose...

Anton
=2D-=20
Anton Piatek
email: an...@pi...=20
blog/photos:                    http://www.strangeparty.com
pgp: [0xB307BAEF]       (http://tastycake.net/~anton/anton.asc)
fingerprint: 116A 5F01 1E5F 1ADE 78C6 EDB3 B9B6 E622 B307 BAEF

[Cajun-users] mpg123 problem. mpg321 too

[Markus G. <sas...@gm...>]

Hi there,

I finished my box a couple of weeks ago. But I encountered mpg123
(compiled from the cajun sources) not playing some songs as I expected.
There just was some chirping and mpg123 was rushing throughthe playlist
within seconds.

In the beginning I thought this is a problem with lack of sufficent RAM.
So I went for another piece of RAM. But sadly I still have this problem.

When I run mpg123 stand alone on these files I get:
Illegal Audio-MPEG-Header

So I replaced mpg123 by mpg321 (debian sarge). Now playing these files
standalone works fine. But if I try to play these within cajun the files
are played without skipping but scattering.
Are there any parameters to fix this (I think cajun uses some parameters
different from the default parameters mpg321 uses)?

Thanks a lot in advance!

Markus

P.S.: Top ´gives me a appr. 85% of CPU use (cajun takes most of the CPU-
Time!) and no swapping

Re: [Cajun-users] writing custom output driver

[Patrick F. <pat...@gm...>]

Already done.  For now, it's in a ZIP file accessible from my jukebox page:
http://users.zoominternet.net/~frazer/jukebox.shtml .  After I get a bit of
feedback and it's proven to be stable on a few CAJUN boxes other than my own
I'll check it into CVS.  There are rough installation instructions on that
web page, but let me know if I've omitted something.

-Patrick


On 11/22/06, Anton Piatek <an...@pi...> wrote:
>
> I wouln't mind the module either. I think it is worth posting on a web
> page,
> or perhaps putting in cvs under conrtib or similar so that the example is
> there for studying (the cvs is public so anyone can get a copy of it).
>
> Anton
>
> On Wednesday 22 November 2006 13:46, Patrick Frazer wrote:
> > project over the summer was to write a custom file playing module
> > based on FilePlayer.pm that behaved the way I thought it should. One of
> > the changes I made was to change the scrolling algorithm so that the
> cursor
> > wasn't glued to line 1 of the display. There are many differences
> between
> > my module and FilePlayer.pm, such as a completely different song queue
> > algorithm, but you should at least be able to see how the modified
> > scrolling behavior is accomplished. (You'd be welcome to use the module
> > as-is, of course)
> >
> > Let me know if you'd like me to send you the module for you to experi
>
> --
> Anton Piatek
> email: an...@pi...       home: 02380 557 995
> mobile: 07900 951 627           work: 01962 816 557
> blog/photos:                    http://www.strangeparty.com
> pgp: [0xB307BAEF]       (http://tastycake.net/~anton/anton.asc)
> fingerprint: 116A 5F01 1E5F 1ADE 78C6 EDB3 B9B6 E622 B307 BAEF
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> Cajun-users mailing list
> Caj...@li...
> https://lists.sourceforge.net/lists/listinfo/cajun-users
>
>
>
>

Re: [Cajun-users] writing custom output driver

[Anton P. <an...@pi...>]

I wouln't mind the module either. I think it is worth posting on a web page=
,=20
or perhaps putting in cvs under conrtib or similar so that the example is=20
there for studying (the cvs is public so anyone can get a copy of it).

Anton

On Wednesday 22 November 2006 13:46, Patrick Frazer wrote:
> project over the summer was to write a custom file playing module
> based on FilePlayer.pm that behaved the way I thought it should. =C2=A0On=
e of
> the changes I made was to change the scrolling algorithm so that the curs=
or
> wasn't glued to line 1 of the display. =C2=A0There are many differences b=
etween
> my module and FilePlayer.pm, such as a completely different song queue
> algorithm, but you should at least be able to see how the modified
> scrolling behavior is accomplished. =C2=A0(You'd be welcome to use the mo=
dule
> as-is, of course)
>
> Let me know if you'd like me to send you the module for you to experi

=2D-=20
Anton Piatek
email: an...@pi...       home: 02380 557 995
mobile: 07900 951 627           work: 01962 816 557
blog/photos:                    http://www.strangeparty.com
pgp: [0xB307BAEF]       (http://tastycake.net/~anton/anton.asc)
fingerprint: 116A 5F01 1E5F 1ADE 78C6 EDB3 B9B6 E622 B307 BAEF

Re: [Cajun-users] writing custom output driver

[Patrick F. <pat...@gm...>]

Rick,

My pet project over the summer was to write a custom file playing module
based on FilePlayer.pm that behaved the way I thought it should.  One of the
changes I made was to change the scrolling algorithm so that the cursor
wasn't glued to line 1 of the display.  There are many differences between
my module and FilePlayer.pm, such as a completely different song queue
algorithm, but you should at least be able to see how the modified scrolling
behavior is accomplished.  (You'd be welcome to use the module as-is, of
course)

Let me know if you'd like me to send you the module for you to experiment
with.

-Patrick



On 11/22/06, Rick Reynolds <ri...@ri...> wrote:
>
> Things seem to be working as designed.  I've got a displayFilter
> definition in place for my 80x25 (25x80?).
>
> Anyway, a couple more questions:
>
> 1. I'm using the InputSocket and OutputSocket devices.  That seems to be
>   decently simple and it allows me to basically write my own app that
> talks to cajun.
>
> I'm wondering about the level of interaction that I can get with the
> socket interface, however.  For instance, when I'm choosing from the
> first level menu, I first see this text:
>
> > View by Artist
>    View by Genre
>    View by Year
>    PlayLists
>
> When I scroll down in the list, cajun only sends me these lines:
>
> > View by Genre
>    View by Year
>    PlayLists
>
> I would have expected to get all 4 back like so:
>
>    View by Artist
> > View by Genre
>    View by Year
>    PlayLists
>
> and of course, when I get to the bottom of the list, I'm only getting a
> single line from cajun:
>
> > PlayLists
>
> How do I write my app so that it knows what to do with this?  It seems
> that I either need to get lines with coordinates so I know where to put
> them, or I should get the whole screen each time.  I guess I'm wondering
> if there's a socket connection equivalent to the
> requestFullDisplayUpdates and requestPartialDisplayUpdates function
> calls that you can make when you're writing a real driver.
>
>
> 2. Now that I have the system basically working, I'm wondering how I can
> hack it to provide more options on the top-most level menu.  My car
> audio system is going to be primarily driven by a very limited UI
> device, a Griffin Powermate.  So I'm wanting to control everything via
> menus and clicks.  So I'd like to be able to add things to the top level
> menu to allow me to choose other functionality.  Such as volume control,
> exiting cajun, maybe even choosing to launch other applications.  Is
> that all driven by data in the database?  Can you point me to the
> location in the code where the logic that ties "View by Artist" to the
> actual functionality that queries the database by artist resides?
>
> Thanks again,
> Rick
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Cajun-users mailing list
> Caj...@li...
> https://lists.sourceforge.net/lists/listinfo/cajun-users
>

Re: [Cajun-users] writing custom output driver

[Rick R. <ri...@ri...>]

> 1. I'm using the InputSocket and OutputSocket devices.  That seems to be 
>   decently simple and it allows me to basically write my own app that 
> talks to cajun.
> 
> I'm wondering about the level of interaction that I can get with the 
> socket interface, however.  For instance, when I'm choosing from the 
> first level menu, I first see this text:
> 
>  > View by Artist
>    View by Genre
>    View by Year
>    PlayLists
> 
> When I scroll down in the list, cajun only sends me these lines:
> 
>  > View by Genre
>    View by Year
>    PlayLists
> 
> I would have expected to get all 4 back like so:
> 
>    View by Artist
>  > View by Genre
>    View by Year
>    PlayLists
> 
> and of course, when I get to the bottom of the list, I'm only getting a 
> single line from cajun:
> 
>  > PlayLists

Now that I've done another experiment, I see that this isn't 100% true. 
  I always get 25 lines from cajun, but only the first N lines have text 
as shown above.  E.g. in the last example, I get "> PlayLists" followed 
by 24 blank lines.

Thanks,
Rick Reynolds
-- 
  It is a mistake to think you can solve any major problems just with 
potatoes. -- Douglas Adams

Re: [Cajun-users] writing custom output driver

[Rick R. <ri...@ri...>]

Things seem to be working as designed.  I've got a displayFilter 
definition in place for my 80x25 (25x80?).

Anyway, a couple more questions:

1. I'm using the InputSocket and OutputSocket devices.  That seems to be 
  decently simple and it allows me to basically write my own app that 
talks to cajun.

I'm wondering about the level of interaction that I can get with the 
socket interface, however.  For instance, when I'm choosing from the 
first level menu, I first see this text:

 > View by Artist
   View by Genre
   View by Year
   PlayLists

When I scroll down in the list, cajun only sends me these lines:

 > View by Genre
   View by Year
   PlayLists

I would have expected to get all 4 back like so:

   View by Artist
 > View by Genre
   View by Year
   PlayLists

and of course, when I get to the bottom of the list, I'm only getting a 
single line from cajun:

 > PlayLists

How do I write my app so that it knows what to do with this?  It seems 
that I either need to get lines with coordinates so I know where to put 
them, or I should get the whole screen each time.  I guess I'm wondering 
if there's a socket connection equivalent to the 
requestFullDisplayUpdates and requestPartialDisplayUpdates function 
calls that you can make when you're writing a real driver.


2. Now that I have the system basically working, I'm wondering how I can 
hack it to provide more options on the top-most level menu.  My car 
audio system is going to be primarily driven by a very limited UI 
device, a Griffin Powermate.  So I'm wanting to control everything via 
menus and clicks.  So I'd like to be able to add things to the top level 
menu to allow me to choose other functionality.  Such as volume control, 
exiting cajun, maybe even choosing to launch other applications.  Is 
that all driven by data in the database?  Can you point me to the 
location in the code where the logic that ties "View by Artist" to the 
actual functionality that queries the database by artist resides?

Thanks again,
Rick

Re: [Cajun-users] writing custom output driver

[Rick R. <ri...@ri...>]

> The problem is that you don't have a screen definition for 80x24...
> we include the 20x4 because it's the most popular size, but
> if you want a custom screen size, you'll have to design the
> screens yourself... and place the fields where-ever you want them
> to go..
> 
> To edit it, go to the OutputSocket driver on "Device Settings", and click
> on "displayFilter". it will probably be empty for a 80x24 screen..
> you'll need to add entries that describe what you want the
> screen to look like for every state that the audio device can
> be in. have a look at the 20x4 one for an example..

Yep, I figured that out eventually.  But I was scouring the code looking 
for some kind of displayFilter module that I had to write.  Not sure why 
I didn't look closer at the web GUI for the 20x4 example.

Looks like I have some work to do...

Thanks again for your patience with all my questions.  Hopefully soon 
I'll have something that I can share back with the user community.

Thanks,
Rick Reynolds
-- 
  Time is nature's way of keeping everything from happening at once. -- 
Woody Allen

Re: [Cajun-users] writing custom output driver

[Paul B. <pa...@ca...>]

Some time ago, Rick Reynolds <ri...@ri...> scribbled.....
> Thanks for the help.  I'm talking sockets to cajun now and things are=20
> 98% there.
>=20
> When the outputsocket device thought the screen was 4x20, things seemed=
=20
> to be working.  I had a little loop that was reading the socket and just=
=20
> dumping the info to the screen so I could see what was going on.
>=20
> I think all I did was change the output dimensions to 25x80, and now I'm=
=20
> not getting the little menu anymore when cajun starts up.  I get this=20
> instead:
>=20
> Welcome to CAJUN...
>=20
> which I hadn't seen before, and now none of my input events are doing=20
> anything.  I can see them scrolling by in the cajun window:
>=20
> InputSocket/13: incoming keystroke: next (j)
> Handling global action audioSelectDown
> WARNING:  OutputSocket/12: OutputDevice: Unknown audiodevice/state:=20
> FilePlayer,selecting
> InputSocket/13: incoming keystroke: next (j)
> Handling global action audioSelectDown
> WARNING:  OutputSocket/12: OutputDevice: Unknown audiodevice/state:=20
> FilePlayer,selecting
> InputSocket/13: incoming keystroke: next (j)
> Handling global action audioSelectDown
> WARNING:  OutputSocket/12: OutputDevice: Unknown audiodevice/state:=20
> FilePlayer,selecting
>=20
> The warnings about unknown state are at least hinting to what the=20
> problem might be, but I don't know what to do to fix it.

The problem is that you don't have a screen definition for 80x24...
we include the 20x4 because it's the most popular size, but
if you want a custom screen size, you'll have to design the
screens yourself... and place the fields where-ever you want them
to go..

To edit it, go to the OutputSocket driver on "Device Settings", and click
on "displayFilter". it will probably be empty for a 80x24 screen..
you'll need to add entries that describe what you want the
screen to look like for every state that the audio device can
be in. have a look at the 20x4 one for an example..

this is how we allow two displays to be connected at once, one
20x4 and one 80x24... they'll each display whatever data they're asked
to.

BTW, for your convenience using FilePlayer in the 'selecting'
state, we set field from "line0" to either "line20" or "line24", so
you can fill the entire screen with data when you're choosing
songs... the 20x4 screen only uses up to line3, of course...

let us know how you do!

-paulb

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
pa...@ca...                  The little girl expects no declaration of=
=20
                                tenderness from her doll.  She loves it --=
=20
                                and that's all. It is thus that we should=
=20
                                love. -- DeGourmont

Re: [Cajun-users] writing custom output driver

[Rick R. <ri...@ri...>]

Thanks for the help.  I'm talking sockets to cajun now and things are 
98% there.

When the outputsocket device thought the screen was 4x20, things seemed 
to be working.  I had a little loop that was reading the socket and just 
dumping the info to the screen so I could see what was going on.

I think all I did was change the output dimensions to 25x80, and now I'm 
not getting the little menu anymore when cajun starts up.  I get this 
instead:

Welcome to CAJUN...

which I hadn't seen before, and now none of my input events are doing 
anything.  I can see them scrolling by in the cajun window:

InputSocket/13: incoming keystroke: next (j)
Handling global action audioSelectDown
WARNING:  OutputSocket/12: OutputDevice: Unknown audiodevice/state: 
FilePlayer,selecting
InputSocket/13: incoming keystroke: next (j)
Handling global action audioSelectDown
WARNING:  OutputSocket/12: OutputDevice: Unknown audiodevice/state: 
FilePlayer,selecting
InputSocket/13: incoming keystroke: next (j)
Handling global action audioSelectDown
WARNING:  OutputSocket/12: OutputDevice: Unknown audiodevice/state: 
FilePlayer,selecting

The warnings about unknown state are at least hinting to what the 
problem might be, but I don't know what to do to fix it.

Thanks,
Rick Reynolds
-- 
  "There are many shades of 12." -- Glenn Beck

Re: [Cajun-users] writing custom output driver

[Paul B. <pa...@ca...>]

Some time ago, Rick Reynolds <ri...@ri...> scribbled.....
> Can anyone point me to a sample perl program or some docs about the=20
> Input/OutputSocket drivers?  Maybe I'm missing something very simple=20
> when looking at the code, but it isn't obvious to me how to write=20
> something that talks to them.

sure, a quick writeup... you'll want to create an inputsocket and
outputsocket driver in cajun.=20

for the inputsocket, assign some readable names for the keys. in
your application, connect to the port number specified in the input
socket driver. every time you send the name of a key (followed by a newline)
to the input socket, it will simulate pressing that key. if the keyname
you send isn't on the keystroke list, it will be ignored. for
simplicity, I often just use single letters for the keystroke names.

for the outputsocket, you'll also form a socket to this driver, using
the port number specified in the cajun web setup screen.  if you have
the 'send screen sizes' box checked, the first thing you'll get is
a number followed by a newline (COLS), and another number followed
by newline (ROWS). these let your application know how big the screen
is, in case you don't want to hardcode it. from then on, every
time the screen updates, you'll receive ROWS lines of output on the
socket, each COLS characters wide. display these as you feel fit...

as an example, in the www/cxterm/src directory is the source for
the java version of cxterm... we do all of this there...

hope that helps!

-paulb

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
pa...@ca...                  The little girl expects no declaration of=
=20
                                tenderness from her doll.  She loves it --=
=20
                                and that's all. It is thus that we should=
=20
                                love. -- DeGourmont

Re: [Cajun-users] writing custom output driver

[Rick R. <ri...@ri...>]

Can anyone point me to a sample perl program or some docs about the 
Input/OutputSocket drivers?  Maybe I'm missing something very simple 
when looking at the code, but it isn't obvious to me how to write 
something that talks to them.

Thanks,
Rick Reynolds
-- 
  Never work for a sawmill that's so behind that they don't have time to 
sharpen the blades. -- Will Hayes, Software Engineering Institute


paulb wrote:
> On Thu, 16 Nov 2006 12:59:18 -0500, Rick Reynolds <ri...@ri...> wrote:
>> Rick Reynolds wrote:
>>> I'm attempting to write an output driver for cajun that will draw to the
>>> computer console screen via curses.  I have a proof-of-concept little
>>> test program working, so I think I have a basic understanding of how to
>>> draw curses stuff, etc.
>> Before anyone starts scratching their head about this, I've verified
>> that the code I've written never returns from this line:
>>
>> $self->{'cui'} = new Curses::UI( -color_support => 1);
>>
>> so there's something funky with the way cajun is calling the curses lib,
>> or maybe some condition that isn't true that curses is expecting.  But
>> it looks like the curses module is exiting, not anything in the cajun
>> code...
> 
> I can't really look at this right now, but you might have an easier time using the InputSocket and OutputSocket drivers... you could write your client in any language that's comfortable to you, and the protocol (if you want to call it that) is insanely simple... have a look at the two drivers, and see if you can use them...
> 
> -paulb
> 
> 

Re: [Cajun-users] writing custom output driver

[paulb <pa...@ca...>]

On Thu, 16 Nov 2006 12:59:18 -0500, Rick Reynolds <rick=40rickandviv.net>=
 wrote:
> Rick Reynolds wrote:
>> I'm attempting to write an output driver for cajun that will draw to t=
he
>> computer console screen via curses.  I have a proof-of-concept little
>> test program working, so I think I have a basic understanding of how t=
o
>> draw curses stuff, etc.
> =

> Before anyone starts scratching their head about this, I've verified
> that the code I've written never returns from this line:
> =

> =24self->=7B'cui'=7D =3D new Curses::UI( -color_support =3D> 1);
> =

> so there's something funky with the way cajun is calling the curses lib=
,
> or maybe some condition that isn't true that curses is expecting.  But
> it looks like the curses module is exiting, not anything in the cajun
> code...

I can't really look at this right now, but you might have an easier time =
using the InputSocket and OutputSocket drivers... you could write your cl=
ient in any language that's comfortable to you, and the protocol (if you =
want to call it that) is insanely simple... have a look at the two driver=
s, and see if you can use them...

-paulb