Hijack v91 is out

Okay, version 91 of the popular Hijack replacement kernel is now available for downloading from http://rtr.ca/empeg/

New in this version is the "restore visuals" function now works for AM/FM/AUX as well as for the Mp3 player mode. The "Tuner+" menu PopUp button has also been fixed.

Coming soon:
-- home docking connector detection, most likely using serial TX->CD loopback.
-- a simple kernel resident FTP server, for remote exploration, backups, etc.
-- improved tuner support, as soon as my docking station is assembled w/tuner.

-ml

Hijack v93 is out:

-- fixed bug in "Force DC/Car Mode" (didn't work perfectly before).
-- remove "Hard Disk Detection" from menu if 2 drives present.
-- allow "menu_remove=label" in config.ini, to remove unwanted items from the Hijack menu system.
-- hacked in code to use TX->DCD for home "dock" detection, currently disabled (see below).

Major setback: I built a home docking station using a spare docking sled for my Mk2, supplying 12V power via the wiring harness. My plan was to loopback the serial TX-data to the (unused) DCD input, as the basis for a way to differentiate between in-car mode and docked mode.

But.. the firmware boot block does a "DC detection" before loading the (hijack) kernel, and omits the "kernel download" prompt when it sees that we're running on DC power. Bummer.. this means my docking scheme is useless, for me at least.

So.. I'll have to modify the station (tomorrow) to insert the AC-Adaptor plug into the back of the Empeg when it is inserted into the dock, in which case I don't need the "dock detection" code. Bummer.

Anyway, since I've already done a similar rigging for the Ethernet plug, it oughta be easy to do something with the AC plug.

-ml

Would there be anyway of adding an option to make the jog dial change to the next song (and previous song) when turned? This would be great for people using the empeg as a seconday device and using like a cd deck for volume controll since the volume on the empeg only needs to be set once and doesnt need to be changed. It would also allow for faster switching through songs.

-Greg

Holy crap, just how fast do you want to flip through your songs? :) Hehe.

Bruno

Hehe... It would just be nice to be able to go to a song you wanted to listen to really quickly without having to do a search or sit there and push the button 30 times. Actually the main reason that i would like this is because my audio seems to find a way to turn itself up and then its blasting when my cd deck is on low.

-Greg

I am not sure I understand this request(?), or if I do, then I'm not sure I understand why..

-ml

OK let me rephrase it. I use my empeg along with my Sony Cd player/radio. The empeg goes into the sony so I only use the sony to controll the volume, not the empeg.

I was woundering if you could put in an option to redefine the jog button. So instead of the volume adjusting when you turn the nob, it instead moves to the next or previous song depending on which way you turn the nob.

The reason i want to do this is (1) so that i can move to different songs a little faster and (2) so that the volume on the empeg doesn't accidentaly get adjusted since this has happned before and almost blew my speakers (the person who was changing the volume didn;t know that empeg was set at a certian volume so that my sony deck wouldnt get too loud)

-Greg

(2) so that the volume on the empeg doesn't accidentaly get adjusted since this has happned before and almost blew my speakers

This can be fixed in 2.0b7, using the default player software. There is an option in the "Settings" menu that allows you to lock the player's volume at a specific level.

Yeah, but it would still be nice to be able to job quickly to a song

-Greg

Yeah, but it would still be nice to be able to job quickly to a song

Yes, this would be nice. I'm skeptical that it would work the way you're hoping it would work, though.

You want to see the track titles scroll quickly past and then settle on a title by twisting the knob back and forth. Sure this would be great, but even if hijack re-mapped the knob directions into left/right commands, it wouldn't work that smoothly.

The player user interface doesn't let you cycle that quickly down the track list, there is some waiting involved if I recall correctly. So there would be no advantage to using the knob and it would probably end up being more frustrating that way-- you'd either overshoot or you'd have to turn the knob more clicks than you wanted to. Also, if you did it too fast, the player would probably misinterpret that as a "held" button and would FF/REW instead of track cycling.

I mean, if the empeg people implemented it directly in the player software, they could make it work the way you wanted. They could make sure to scroll the track titles instantly and let the cache catch up later. But I don't think it works that way right now.

Watch, now, Mark will implement it and prove me wrong...

>remove "Hard Disk Detection" from menu if 2 drives present.
Entry is present, even if I have a two drive player.

I think what you want can be done with some creative IR translation. Hijack sees the knob rotations as IR codes:

#define IR_KNOB_RIGHT			0x0000000a

#define IR_KNOB_LEFT			0x0000000b

So I'm thinking that if you added the following to your IRTrans section, it might turn it into a jog dial, of sorts:

a=20DF11

b=20DF10

No promises though. Give it a shot.

>remove "Hard Disk Detection" from menu if 2 drives present.
>Entry is present, even if I have a two drive player.

Let me guess.. Mk1 player, right?

-ml

No, the [ir_translate] suggestion won't work for knob codes. These are special, in that there is no "release" code for a knob rotate left/right. When I first coded ir_translate, I was having trouble with the knob stuff confusing things, so I just disabled knob translations. Even the knob press/release is strange, in that the release actually generates two release codes internally.

/me stands corrected.

No, it's a MK2a.
Two IBM drives 18 and 20 GB

All front panel buttons on mk2s (and onward) generate 2 up codes and 1 down. The mk1 had previously had issues with the up codes getting lost due to interrupt latency, so the mk2 button PIC on the frontboard generated longer fake-IR sequences to send to the main board and sent up twice. It's rather belt&braces, but works fine.

We since fixed the problem with mk1s by moving the IR from irq to fiq.

Hugo

Okay, found & fixed --> Hijack v94.

v94 also now boots faster on Mk1 single-drive systems, and slightly faster than before (1/8 second) on Mk2 single-drive systems.

-ml

That's very useful to know, thanks -- it also explains how Hijack (and me) got very confused about those buttons, many releases ago..

Cheers

>I was woundering if you could put in an option
>to redefine the jog button. So instead of the volume
>adjusting when you turn the nob, it instead moves
>to the next or previous song depending on which way
>you turn the nob.

Okay, as unlikely as this sounded when I first read it, it actually works! I've implemented a static (compiled-"in") translation for this, and it actually can very quickly scroll through a playlist. Much faster than using the next/prev track buttons (which seem very slow to me, btw).

So I'll work on a menu selection for this behaviour in v95 (not out yet).

-ml

Damn, I knew you would prove me wrong.

I had a feeling that would happen, since I thought one of the improvements in 2.0 was the ability to move quickly between tracks without needing to wait on the drives to spin back up.

Well, give it a spin and see how theory == reality, almost.

v95.

All i can say is SWEEET.. hehe... I hope others will find this useful. I know I will.

-Greg

Track to track times have slowed in b7 :) Playlist culling has also slowed (not talking about randomizing either :)

Bruno

Mark, I just dropped v98 on my Empeg and things look great. However I was doing some thinking about the knob, and it looks like you have found a way to detect when the knob is spinning *while being pushed down* versus when it's spinning normally (i.e. you're throwing away knob rotations that occur while the knob is pressed.)

Well howzabout an option to have that kind of knob rotation (a "push and twist" sort of) mean something? Like maybe the normal behavior is volume, and push and twist fast-forwards, or skips tracks, or whatever. That *somewhat* defeats the purpose of the feature I asked for (throwing away the first couple twists in any direction to avoid "operator error") but maybe if this "dual mode" knob was activated, you could just throw away the *first* press in any direction while the button is being pressed, and process the rest.

Does any of that make sense?

I thought about that sort of functionality, and even attempted some trials with it.. doesn't work nicely in practice. It was just too difficult to keep the knob reliably pushed in while spinning.

So no loss.

What if you implemented it so that pushing and spinning got into that mode where it stayed until a timeout or an additional knob press. That way, you could start the push-and spin, but you don't have to actually keep it held down for long spins. Of course, you'd have to check the breakout press to make sure that it isn't a continuation of the press-and-spin.

I agree that while driving in a car it might be tough to push and twist... Hmm.

Then how about the idea I asked the Empeg guys to implement... A single knob push toggles it between two different states. In one state, it controls volume, in the other, maybe it seeks within the song, or jogs between songs... In fact you could make it three states... There'd have to be some visual feedback as to which you're in, maybe a tiny icon in the bottom right or something. And maybe some audio beeps... Hm.


edit: It wasn't until after I posted this that I realized how funny that "push and twist" comment sounds... Somewhere, Beavis and Butthead are laughing hysterically.

I second that idea.

what I;d like to see the knob be able to do is:

1. Volume up/down [default behaviour now]

2. Skip forward or back quickly in playlist [newly added option]

3. Cycle forward and back through visuals quickly ala 2 above

4. Same for preset stations in Tuner mode [i.e. skip forward/back through the presets quickly]

Now the big problem is how to have all of these available on one knob and let the user select which one they want active at the given time.

Option 4 would be only active if in Tuner mode and would logically replace option 2 as the concept of a playlist is replace by preset stations in the Tuner mode.
1 & 3 would be wanted in all source modes so they need to be active one at a time only.

I think this could be done as another option on the 'push the knob menu options', i.e. a new mode that allows you cycle amoungst these options [only] , each successive knob push advances to the next knob turning option and when the last one is reached, back to the beginning again.

[the way to leave this option is via the hijack menu options using a long push]

The other thing I would like to see is some way of getting at and mapping the Sony Stalk Interface 'keys' ala the IR mapping function - I'm not sure how the Stalk is supported - by the player directly or within the Kernel or what.
Obviously the latter would be easy to get at and remap, the former much harder but still do-able I guess as I assume the Sony Stalk commands still get sent to the player software via the kernel somehow.

Having had a Stalk Interface for a while I find it nearly as useful when in the car as the front knob buttons - but of course not everyone has a Sony Stalk Interface as it requires a Tuner module which as we know are in short supply.

>1. Volume up/down [default behaviour now]
>2. Skip forward or back quickly in playlist [newly added option]
>3. Cycle forward and back through visuals quickly ala 2 above
>4. Same for preset stations in Tuner mode
> [i.e. skip forward/back through the presets quickly]

Well, #2 and #4 are exactly the same solution, implemented already, but as a separate main menu item.

The player software does not currently have any way to implement #3 (going backwards through visuals), much as we'd all like to have it.

#1 is already there.

The interface for something like this would likely be just like the current PopUp list, just adding more options to it. Hit the knob, get a popup, scroll to the desired action, press again, and then you're in the "scan forth/back" or whatever action you wanted.

But I will leave this be for now, until the concept and feature list matures a little more. Right now, there's just not enough new capability there to be worthwhile, since most/all of it already exists in a reasonable fashion. But someday..

Meanwhile, I haven't touched my ftp server code since Christmas Eve.. gotta get back to work on it.

-ml

It seems to me that if there is a way to modify the player software to implement the concept of modes (setup and playback) then in setup mode, pushing the knob will repeatedly bring up settings to dial in. If it is in playback mode, pushing the knob repeatedly will bring things up like "Visuals" "Song Scan" "Song Skip" that sort of thing. So if you bring up "Visuals" it pops up a bar graph that looks a lot like "Loudness" except when you twist the knob it spins through all the available visuals. Ditto with songs, etc etc.

Like somebody else said, if you're tweaking settings, you're likely to want to tweak all sorts of different settings. Once dialed in, setup mode can be exited. When you're playing back songs, you're likely to want to do all manner of things related to playback (pick visuals, pick songs, shuttle through a song, etc, etc) and want nothing at all to do with loudness, fader, balance--that stuff is wasted!

Calvin

The player software does not currently have any way to implement #3 (going backwards through visuals), much as we'd all like to have it.

Does the player ever re-read the flash block? If we changed the value in flash would the player ever catch on? It just occurred to me that something like this might allow you to go backwards through the visuals, but more interestingly be a good way to get randomly changing visuals which people have been begging for forever.

Actually there is of course an easier way to change visuals. You would make a lot of people happy if you added the ability to send the visual change IR code every few minutes or at some other interval (can you tell when the song changes as a side effect of the timecodes stuff added recently?). Please?

-Mike

In reply to:

---

The player software does not currently have any way to implement #3 (going backwards through visuals), much as we'd all like to have it.

---

Well something does have the ability to go forward AND backwards in the visuals on the player.
When using the Sony stalk interface [which I have] the push and turn sequence on the stalks volume up/down buttons causes next/previous preset in Tuner mode and next/previous visual in Player and Aux in mode.
[when this knob is turned without pressing it in against the inner ring it does the Volume up/down (only) function]

This handling of the forward and backwards visuals selection may be done in the player itself - which would indicate that the other half of my original post about where the Stalk interface is actually handled - in the kernel or in the player - has sort of been answered and the Player software itself does it [given the current statements made about not being able to send the player a 'go back 1 visual' IR code.].

Still even being able to cycle Forward through the visuals via the front knob would be useful.

Still a question remains can we send the player 'fake' Stalk Interface commands, and if so, then we can implement forward and backward visuals that way can we not?

BTW: I also like the idea of it beting able to switch to another visual [either next or random visual] on either a fixed timer or a semi-random timer.

My original post stems from my belief that the wonderful capabilities of the knob up to now are being sadly underused - such a simple and elegant input device can allow users to do things with a turn of the knob that many button presses would be required any other way and we are not using it to its full potential.

[Seeing what the empeg guys did with the Stalk interface knob gives some idea of what can be achieved but thats only available if you have the tuner and the Stalk].

>When using the Sony stalk interface [which I have] the push
>and turn sequence on the stalks volume up/down buttons causes
>next/previous preset in Tuner mode and next/previous visual
>in Player and Aux in mode.

Great! So just fire up the Hijack "Show Button Codes" screen, and tell us all what code it sends.. then ANYONE can use [ir_translate] to remap it to a standard key! (and plus, I might add something to Hijack for it).

-ml

In reply to:

---

Great! So just fire up the Hijack "Show Button Codes" screen, and tell us all what code it sends.. then ANYONE can use [ir_translate] to remap it to a standard key! (and plus, I might add something to Hijack for it).

---

I tried this, unfortunately this produces no codes - this must mean that the Stalk Control is done directly by the Player software. :-((((

Now, the question is if we could find out how the Stalk Interface is done by the player could we do a similar hack to the RDS hack but feed 'fake' Sony Stalk messages to the Player [and also of course feed the real Stalk messages to the same mappable Interface we have now for the normal buttons and IR codes].

I guess we need the input from the Empeg software guys on this one as this is under the control of the player.
I don't even know how the Stalk is 'read' - does it have its own device or does it share things with the Tuner [and is this controlled via IOCTLs or just by opening and 'reading'].

I suppose the stalk commands MUST come in over the Tuner's serial port, possibly concealed as RDS packets.

Can you hook it up, and watch /dev/rds1 (requires a recent Hijack, and you'll need to create it with: "mknod /dev/rds1 p") to see what happens (if anything) when using the stalk?

-ml

the Sony Stalk commands won't be pretending to be RDS packets as the RDS processing is done within the DSP [Altman (Hugo) told me this about 6 months ago when I asked about the Sony Stalk Interface and RDS Tuner interface and Tuner interface pinouts].

He also indicated that the 'serial' interface between the tuner and player is used for send tuning commands to the tuner module and to get Sony Stalk 'buttons' as well as signal strength information and tuning info.

The Stalk buttons are managed in the Tuner by a PIC Micro and the ADC values read are output to the unit via the serial interface.

So the likely device to read is /dev/tuner as thats where the data will be turning up.

How difficult would it be to 'monitor' the traffic between the player and /dev/tuner? [I imagine a simple trace facility intially - possibly in the kernel that dumps all tuner interface traffic in human readable form to the serial port and from that we can work out whats going on].

No, RDS is totally internal to the player - the tuner just sends the FM multiplex (L/R/RDS).

The stalk commands come in over the tuner module's tty.

Hugo

Hugo,
Are you saying that the Stalk commands are available via the /dev/tuner interface or are you suggesting that we go lower and actually monitor the serial packets coming in on the /dev/ttyS? interface that connects the Tuner to the empeg?

If so, what particular packets on this Interface should be looking for to 'snag' the Stalk Interface packets?
[I know you said the protocol between the tuner module and the empeg is quite a simple one but its never been documented - is this something that can change now the player is EOL?



BTW: Hugo - I apologise for misquoting you about the DSP - yes I recall now that you said that the FM multiplex is processed by the DSP and RDS data is sent to the player software via the /dev/rds0 interface.

>The stalk commands come in over the tuner module's tty.

Do those commands pass through kernel space at all?
If so, where..? I want to intercept them and allow IR translations on them.

Thanks.

ISTR I noted what the packets were in another post. 4 bytes, starting with 02 xx yy (xx+yy) where xx is the shift value and yy is the ADC reading. ISTR, anyway.

I also STR it's 19200, 8n1 on ttyS0(?). Not near anything to check at the moment!

Hugo

Yep, I can confirm this information.

Info I get from my Empeg is as follows:

Stalk /Tuner is on /dev/ttyS0, at 19200 - the Player needs to send some command(s) to the Tuner before this becomes active, don't know what the 'enable' command is.

Each Stalk button sends a 4 byte packet in the format as per Hugos post.

Format is [in hex] 02 XX YY XX+YY where 02 means Stalk command I guess, XX is the Stalks 'Shift Value' either 00 for 'unshifted' buttons [i.e. Volume knob NOT pushed in] and 01 for Shifted buttons [i.e. Volume knob pushed in].

YY is the ADC value for the button being read and it does hover around the number a little [you need to test for the ADC value being between YY +/-F where F is the Fudge factor [around 5-10 for F is I think ok to cater for most Stalk variations].

The last byte is the Sum of XX+YY.

The Stalk Interface sends two command packets per button, once for Key Down and once for Key Released.
It doesn't send any timing info but you could determine if its a 'long' press by timing how long the down packet arrives before the up packet.

Key Release has FF as the YY value in all cases.

You also get a seperate 'key' release packet whenever the shift key is released [with XX being 01 rather than 00 , but YY is still FF].

You can grab Stalk commands from the Interface once the player has been running by stopping the player, then a
od -t x1 -v -w4 (redirect stdin from /dev/ttyS0)
will dump the 4 byte packets to the console as you fiddle with the Stalk buttons.

For the record heres the dump of the packets my Stalk makes the Tuner send to the empeg
:
[with comments about each button just pressed preceding each bunch of packets]

Note: Stalk is mounted on Steering wheel RHS on this installation [i.e. setting in emplode says RHS Stalk].

Off Button is to the Front [facing driver] and ATT button is behind [facing the dashboard]. The 3 buttons I called Front, Rear and Underneath are facing the Driver, the Dashboard and pointing to the floor of the vehicle respectively.

These 3 buttons are un-named by Sony as their exact Function depends on the Sony head unit the Stalk is plugs into.

On the Empeg these 3 buttons perform the Menu, Cancel and Shuffle on/off toggle in that order [i.e. Front button does Menu, Rear does Cancel and underneath button does Shuffle in my setup].

Note: for LHS of Steering wheel Stalk installations - Menu and Cancel are swapped, Off and ATT stay with the button of the same name and the meaning of Vol+/Seek+ etc is reversed [i.e. Seek+ becomes Seek- and v/v when in the LHS Stalk config].

Heres the dump of each button press then release on od format, ignore the address part at the front of each packet thats od showing the current offset in the stream [shows no packets are missing and little else :-) ]

Source button pressed (& released)

0000000 02 00 17 17

0000004 02 00 ff ff



Vol+ pressed (& released) etc

0000010 02 00 85 85

0000014 02 00 ff ff



Vol- Pressed

0000020 02 00 6f 6f

0000024 02 00 ff ff



Seek+

0000030 02 00 5b 5b

0000034 02 00 ff ff



Seek- [RHS stalk]

0000040 02 00 49 49

0000044 02 00 ff ff



Off

0000050 02 00 01 01

0000054 02 00 ff ff



ATT

0000060 02 00 2c 2c

0000064 02 00 ff ff



Front Button [menu in RHS config]

0000070 02 00 3b 3b

0000074 02 00 ff ff



Rear button [cancel in RHS config]

0000100 02 00 9b 9b

0000104 02 00 ff ff



Underneath button [Shuffle in RHS config]

0000110 02 00 b0 b0

0000114 02 00 ff ff



Shift pressed and released [no other buttons used]

0000120 02 01 ff 00

0000124 02 00 ff ff



Shift+Vol+ (i.e. shifted Vol+)

0000130 02 01 ff 00

0000134 02 01 5b 5c

0000140 02 01 ff 00

0000144 02 00 ff ff



Shift+Vol-

0000150 02 01 ff 00

0000154 02 01 49 4a

0000160 02 01 ff 00

0000164 02 00 ff ff



Shift+Off

0000170 02 01 ff 00

0000174 02 01 02 03

0000200 02 01 ff 00

0000204 02 00 ff ff



Shift+ATT

0000210 02 01 ff 00

0000214 02 01 2b 2c

0000220 02 01 ff 00

0000224 02 00 ff ff



Shift+Front button

0000230 02 01 ff 00

0000234 02 01 3b 3c

0000240 02 01 ff 00

0000244 02 00 ff ff



Shift+Rear Button

0000250 02 01 ff 00

0000254 02 01 9b 9c

0000260 02 01 ff 00

0000264 02 00 ff ff



Shift+underneath button

0000270 02 01 ff 00

0000274 02 01 b0 b1

0000300 02 01 ff 00

0000304 02 00 ff ff



Shift+Source Button

0000310 02 01 ff 00

0000314 02 01 17 18

0000320 02 01 ff 00

0000324 02 00 ff ff

Note: there is no shifted Seek+/Seek- as due to the way the Stalk is made Shifted Vol+ is the same as Shifted Seek+ [when the volume knob is pushed in to the shift position it physically locks against the inner ring that has the Seek+/- buttons on it so that the two buttons become one and turn together while shift is held in so it can only report it as one button].

Note that the Shifted buttons produce 4 packets, one for the shift, one for the Button pressed, one for the button release and one for the shift release.

The order of these 4 packets could vary, e.g. if you did the following:
Front button press,shift press,release Front button, release shift you would get 4 packets like this:

0000330 02 00 3b 3b

0000334 02 01 3b 3c

0000340 02 01 ff 00

0000344 02 00 ff ff

So any mapping in hijack needs to handle this situation.
You can also get the situation where the key is pressed [and held] then the shift key is pressed and held, then one key is released then the other - so the order the packets can vary depending on how the shift and other button is pressed and released.

I also think that the shift push then shift release [ie no other key shifted just the shift key is pushed then release] could be used as another button in its own right as its dead easy to do on the stalk and could logically act like a modifier key and be used to modify the behaviour of keystrokes that follow.
Its also easy to detect as the shift pressed and shift released packets arrive adjacently.

If you press two keys [and one of them is not shift] then the button with the lower ADC (YY) value blocks the other button until the lower ADC value key is released and it generates a key release packet for the lower ADC value button just released, then you get the key press packet for the higher key.

So, hopefully all this will lets us do some real hacking/mapping of the Stalk IF when Mark gets a chance.


BTW: I think we need to make the fudge factor (F) for the YY +/- range values configurable as previous stalk users have posted about problems with stalk commands not being picked up by the player in all cases and this has been suggested is due to the variations in resistance that each stalk button naturally has - its a analogue device after all!
Some users may find they need larger values of F.
I would think that only one value of F is needed i.e. the same value is applied to all Stalk ADC values.

Wow, what a post.

Please please please e-mail drakino or someone to get this put up at the developer section of riocar.org.

Got it.

Yup, see that. Cool, thanks.

theres one thing missing from my post [got chopped off by the BBS]. Can someone add this to the copy of the earlier post?

Here is why there is no Shifted Seek+/Seek- buttons but there are shifted version of every other button :

On the Sony Stalk device when the Volume knob is pushed in [i.e. shifted], it physically engages with the inner ring next to the Volume up/down knob which has the Seek +/- buttons on it and the volume +/- button and the Seek+/- button turn as one button until the volume knob is no longer pushed in.

The Shifted Seek/Vol+ actually reports as a shifted Seek+/- button even though I call it Shift Vol+/Vol-

This design of the Sony Stalk means that there are 10 unshifted keys [count them] on the Sony Stalk, but only 8 shifted keys.

Still 18 useable keys plus a modifier [push and release shift button] makes for more potential buttons functions on the Stalk Interface than the original Kenwood remote has/had.

Believe me, the Stalk Interface is just as good as, if not *better* than the remote [even the new Rio one] and I hardly ever use the remote anymore.

There are a couple of things the Remote can do that the Stalk can't but we hope to rectify that real soon now - hence this post and the earlier one.

I think I squeezed it in there... Not sure where you wanted it to go in relation to the other stuff. Plus for some reason if I put it at the end, it's not automatically word-wrapping the text so I had to put it further up. I've seen this happen with text on the BBS as well. I don't know if it's a goofy IE6 thing or what.

Put it after the bold text quoted below and replace the non-bolded text in the square brackets in the original post with the posted text to make it read correctly and put it in context.

In reply to:

---

Note: there is no shifted Seek+/Seek- as due to the way the Stalk is made Shifted Vol+ is the same as Shifted Seek+ [when the volume knob is pushed ...]

---

Okay I think I got it. Actually with Drakino's permission I would like to re-organize the developer info section a little bit so things are easier to find. Two somewhat redundant software sections, two somewhat redundant hardware sections, and a "miscellaneous stuff" section isn't ideal, methinks.

Cool, I like that idea. It needed the re-org.

Hi.

You have got my permission to reorganize the contents of the two incase.de-related sections in any way you think would be appropriate. I just added those because I didn't want to temper with someone else's texts without his explicit permission, to I left the other sections alone.

However, I am not pleased that you did not contact me before actually tempering with my material. You should have known better than that.

If you do anything else with my content without informing me at least within a few hours of the actual change, I will really get angry about that.
Those sections weren't named with the tag "incase.de" in their respective names without reason. They were named that way because I felt responsible for them (even if I didn't have as much time to spend maintaining them as I would have liked).

cu,
sven

Sven,

I have to say I am rather surprised by this reaction. If you hadn't noticed, I tried to give you full credit for the information you added in the tagline of each section ("Contributed by..."). Drakino gave me the go-ahead to reorganize things and I didn't want to have to contact 15 different authors to see if it was okay if I simply moved their material somewhere else. I didn't take any credit for your sections, nor did I change any of the content. I hadn't finished reorganizing things, so I think I might have not gotten to one or two of the sections for which you were responsible, but I have it all written down on a sheet of paper here, and it's on my list.

The section is still evolving and I was just trying to move things around. I thought as long as I gave you credit, there was no need to ask permission simply to move it to another section. I apologize for this oversight and I'l try to ask next time.

But really I thought that once someone contributed something to riocar.org, it was somewhat public domain. I at least tried to give you credit, and I'm sorry that wasn't sufficient.

Hi.

But really I thought that once someone contributed something to riocar.org, it was somewhat public domain. I at least tried to give you credit, and I'm sorry that wasn't sufficient.

Don't get me wrong, my previous message was probably a bit too harsh, but mainly I am concerned that you took my work apart: The developer info that was collected under the two main groups of hardware- resp. software info (provided by www.incase.de, as stated in the groups' names) was pretty much my work, even if I "only" collected those infos from the BBS, from available sources and some emails. Now you took those collections that I created apart again, without asking for my permission.
See, I contributed those collections to the riocar.org site as they were (and sharing most of the HTML sources with my own homepage at www.incase.de) because drakino asked me if I would take responsibility of the developer section of the BBS. I agreed to that request, and now (without any direct notice to me), this responsibility is suddenly taken away, and my previous work <irony>all messed up</irony>.
I don't have any problem with you taking over some (or even all) responsibility of the developer section (mainly because I don't find enough time to work on it), I am just a tiny little bit pissed because of the way it happened. That isn't exactly your fault.
In other words: I would be thankful if you would actually reinstall some reference to my homepage again, at least on those FAQ entries that are already marked as "contributed by Sven Müller". Other than that, please just keep me informed if you change any content that I created, and everything is fine.
Anyway, your reorganization of the developer section seems to be well thought about, and pretty clean. Keep up that good work, and if I can help you in any way, just ask. If you find some errors that are in my texts, please inform me of those, so that I can also fix my homepage accordingly. I don't have much (sometimes not even little) time to spend on that, but it should be enough time for a little fix-up here and there.

cu,
sven

Sven,

You haven't been demoted to anything, and I haven't been promoted to anything. I was simply given access to add some information I had researched, and when I couldn't figure out where to add my own information (two software sections), I thought it could benefit from some re-organization. So your statement that some responsibility has been taken away from you and somehow given to me is incorrect. I'm just trying to help out.

Look, you've contributed a LOT of well-organized and valuable content, which is why I didn't change any of it, and credited you. I don't want this to leave a bad taste in your mouth, and I will happily add your site's URL to each of your contributions (actually I just did.)

Let's drop the politics here, I wasn't elected the Grand Master of the Developer Section, I just wanted to contribute, and had some free time over this past weekend. As you get more free time, feel free to add more stuff, or move anything around that seems illogical. I just wanted to see what I could do to make things easier to find. Hopefully some of these newbies who might be future Empeg hackers will have easier access to the infomation than we had when we were learning the ropes. That's what it's all about, right?

Oy, I didn't know this would turn into a mess like that, but it looks like it was worked out as well by the time I got here.

I'm making it official policy now to give credit in any of the sections like the FAQ, Developer Info, etc... Link to relevant posts over here if necessary, but at least have a name.

Sven, you still have full access like you did. I recently gave yn0t access so he could add some info. He reorganized the area, I looked it over, and approved it. I appologize for not thinking to consult with you as well on this. Mark Lord also has access, so that way he can add any info he wants to, if the Hijack development ever slows. (The admin side of riocar.org is definitly not set up for easy, quick updates). Other admins include Rob, Hugo, and Richard L. If anyone else wants access, consult me via e-mail. If you are not well known by the community, please post info here, and one of the admins can then transpose it over to the site.

I definitly wanted RioCar.org to have several key admins, not just myself. This way, the site won't suffer the same "information rot" that overtook empeg.mars.org. I am working from time to time on a new riocar.org that hopefully will have user submittions for the FAQ and Developer Info sections. This should increase content without increasing the admin count to a huge amount.

Hi.

Oy, I didn't know this would turn into a mess like that, but it looks like it was worked out as well by the time I got here.

Right. Let's just get on with the work and put "the politics aside" like some valuable person said before.

I was just a bit frustrated about the way this happened, but I'm over it now, thanks to the great work Tony did with the reorganisation. I will hopefully contribute some more information to the developer section soon, and if all goes well, that will even include a compile-by-mail service (that would even allow for more complex projects that require the use of makefiles) run on my home Linux server.

cu,
sven
(now returning to that damned kernel compile that doesn't seem to work right).

a compile-by-mail service ... run on my home Linux server

Don't bother. So far, only one person has taken me up on my shell account for cross-compiling yet. And he's the one that spurred me to do it in the first place. Maybe I'll bump it up to the top to make sure that folks didn't miss it.