http://sessrumnir.net/fernseher/api.php?action=feedcontributions&feedformat=atom&user=Admin 2026-07-01T02:29:48Z User contributions MediaWiki 1.37.1 http://sessrumnir.net/fernseher/index.php?title=GPS_clock&diff=106767 2017-03-23T21:07:33Z

<p>Admin: </p> <hr /> <div>There are two separate yet related goals here:<br /> * Create a local timeserver for my network, based on a GPS time-source on a raspberry-pi.<br /> ** Should use a 1PPS capable GPS module.<br /> ** Doesn&#039;t really need a display, though it can have one.<br /> ** Wired networking is fine<br /> ** I think it can almost entirely be based on existing packages, like gpsd, ntpd, etc.<br /> * Create a standalone clock, using a GPS source, based on a raspberry-pi<br /> ** GPS can be a simple cheap, available one.<br /> ** Doesn&#039;t really need super-accurate inter-second timing, we&#039;re only going to display to the nearest second anyway.<br /> ** Absolutely needs a display of some sort<br /> ** Should be able to work with no network at all. If wireless is available, to do FW updates or something, bonus.<br /> ** Power usage is somewhat of a concern, though could start out using wall-wart power<br /> ** A big 5&quot; or 7&quot; touch display is way overkill, but could display sun location, etc, and use touch for setup<br /> ** Use GPS co-ords to pick local timezone.<br /> ** OLED screen and batteries?<br /> ** Could we get away with solar power?<br /> ** low-power mode is a goal to get us off the plug<br /> ** any way we can have it turn the display off when its not light out? or when I&#039;m not looking at it? :)<br /> <br /> ==Things to Display==<br /> * Date &amp; Time in several formats:<br /> ** UT1<br /> ** UTC<br /> ** Unix<br /> ** Local<br /> ** MST<br /> ** AST<br /> * Number of satellites used in fix<br /> * Battery power left<br /> * Day of week (text) and month of year (text) and week of year (numeric, ISO)<br /> * Time to sunset/since sunrise<br /> * Temp/humidity/pressure<br /> * latitude/longitude<br /> * local time-zone<br /> * DST active<br /> <br /> ==Things to Adjust==<br /> * Ideally nothing, other than date/time display preferences:<br /> ** 12-hour/24-hour?<br /> ** ISO formatting options?<br /> ** which time choices (above) to display at all times<br /> * Other localization settings &amp; options<br /> ** C/F for temp<br /> ** Power-saving settings?<br /> * Some way to initiate FW updates?<br /> ** Would be cool if it would detect when my phone is making Wifi available, then:<br /> *** connect to that<br /> *** check git for FW updates (or somewhere)<br /> *** check somewhere for OS and kernel updates<br /> *** update itself if needed<br /> *** reboot/restart app if needed<br /> <br /> ==Anything else to make available?==<br /> * Maybe a calculator? phone or laptop is more convenient, probably<br /> * Some sort of calendar mode? Again, for something like this, more than a glance, phone/laptop more convenient<br /> * Something else I could see at a glance? Home status?</div>

Admin http://sessrumnir.net/fernseher/index.php?title=GPS_clock&diff=106766 2017-03-23T21:07:15Z

<p>Admin: </p> <hr /> <div>There are two separate yet related goals here:<br /> * Create a local timeserver for my network, based on a GPS time-source on a raspberry-pi.<br /> ** Should use a 1PPS capable GPS module.<br /> ** Doesn&#039;t really need a display, though it can have one.<br /> ** Wired networking is fine<br /> ** I think it can almost entirely be based on existing packages, like gpsd, ntpd, etc.<br /> * Create a standalone clock, using a GPS source, based on a raspberry-pi<br /> ** GPS can be a simple cheap, available one.<br /> ** Doesn&#039;t really need super-accurate inter-second timing, we&#039;re only going to display<br /> to the nearest second anyway.<br /> ** Absolutely needs a display of some sort<br /> ** Should be able to work with no network at all. If wireless is available, to do FW updates or something, bonus.<br /> ** Power usage is somewhat of a concern, though could start out using wall-wart power<br /> ** A big 5&quot; or 7&quot; touch display is way overkill, but could display sun location, etc, and use touch for setup<br /> ** Use GPS co-ords to pick local timezone.<br /> ** OLED screen and batteries?<br /> ** Could we get away with solar power?<br /> ** low-power mode is a goal to get us off the plug<br /> ** any way we can have it turn the display off when its not light out? or when I&#039;m not looking at it? :)<br /> <br /> ==Things to Display==<br /> * Date &amp; Time in several formats:<br /> ** UT1<br /> ** UTC<br /> ** Unix<br /> ** Local<br /> ** MST<br /> ** AST<br /> * Number of satellites used in fix<br /> * Battery power left<br /> * Day of week (text) and month of year (text) and week of year (numeric, ISO)<br /> * Time to sunset/since sunrise<br /> * Temp/humidity/pressure<br /> * latitude/longitude<br /> * local time-zone<br /> * DST active<br /> <br /> ==Things to Adjust==<br /> * Ideally nothing, other than date/time display preferences:<br /> ** 12-hour/24-hour?<br /> ** ISO formatting options?<br /> ** which time choices (above) to display at all times<br /> * Other localization settings &amp; options<br /> ** C/F for temp<br /> ** Power-saving settings?<br /> * Some way to initiate FW updates?<br /> ** Would be cool if it would detect when my phone is making Wifi available, then:<br /> *** connect to that<br /> *** check git for FW updates (or somewhere)<br /> *** check somewhere for OS and kernel updates<br /> *** update itself if needed<br /> *** reboot/restart app if needed<br /> <br /> ==Anything else to make available?==<br /> * Maybe a calculator? phone or laptop is more convenient, probably<br /> * Some sort of calendar mode? Again, for something like this, more than a glance, phone/laptop more convenient<br /> * Something else I could see at a glance? Home status?</div>

Admin http://sessrumnir.net/fernseher/index.php?title=GPS_clock&diff=106765 2017-03-23T21:04:26Z

<p>Admin: </p> <hr /> <div>There are two separate yet related goals here:<br /> * Create a local timeserver for my network, based on a GPS time-source on a raspberry-pi.<br /> * Should use a 1PPS capable GPS module.<br /> * Doesn&#039;t really need a display, though it can have one.<br /> * Wired networking is fine<br /> * I think it can almost entirely be based on existing packages, like gpsd, ntpd, etc.<br /> * Create a standalone clock, using a GPS source, based on a raspberry-pi<br /> - GPS can be a simple cheap, available one.<br /> - Doesn&#039;t really need super-accurate inter-second timing, we&#039;re only going to display<br /> to the nearest second anyway.<br /> - Absolutely needs a display of some sort<br /> - Should be able to work with no network at all. If wireless is available, to do FW updates or something, bonus.<br /> - Power usage is somewhat of a concern, though could start out using wall-wart power<br /> - A big 5&quot; or 7&quot; touch display is way overkill, but could display sun location, etc, and use touch for setup<br /> - Use GPS co-ords to pick local timezone.<br /> - OLED screen and batteries?<br /> - Could we get away with solar power?<br /> - low-power mode is a goal to get us off the plug<br /> - any way we can have it turn the display off when its not light out? or when I&#039;m not looking at it? :)<br /> <br /> ==Things to Display==<br /> * Date &amp; Time in several formats:<br /> - UT1<br /> - UTC<br /> - Unix<br /> - Local<br /> - MST<br /> - AST<br /> * Number of satellites used in fix<br /> * Battery power left<br /> * Day of week (text) and month of year (text) and week of year (numeric, ISO)<br /> * Time to sunset/since sunrise<br /> * Temp/humidity/pressure<br /> * latitude/longitude<br /> * local time-zone<br /> * DST active<br /> <br /> ==Things to Adjust==<br /> * Ideally nothing, other than date/time display preferences:<br /> - 12-hour/24-hour?<br /> - ISO formatting options?<br /> - which time choices (above) to display at all times<br /> * Other localization settings &amp; options<br /> - C/F for temp<br /> - Power-saving settings?<br /> * Some way to initiate FW updates?<br /> - Would be cool if it would detect when my phone is making Wifi available, then:<br /> * connect to that<br /> * check git for FW updates (or somewhere)<br /> * check somewhere for OS and kernel updates<br /> * update itself if needed<br /> * reboot/restart app if needed<br /> <br /> ==Anything else to make available?==<br /> * Maybe a calculator? phone or laptop is more convenient, probably<br /> * Some sort of calendar mode? Again, for something like this, more than a glance, phone/laptop more convenient<br /> * Something else I could see at a glance? Home status?</div>

Admin http://sessrumnir.net/fernseher/index.php?title=GPS_clock&diff=106764 2017-03-23T21:04:08Z

<p>Admin: </p> <hr /> <div>There are two separate yet related goals here:<br /> * Create a local timeserver for my network, based on a GPS time-source on a raspberry-pi.<br /> - Should use a 1PPS capable GPS module.<br /> - Doesn&#039;t really need a display, though it can have one.<br /> - Wired networking is fine<br /> - I think it can almost entirely be based on existing packages, like gpsd, ntpd, etc.<br /> * Create a standalone clock, using a GPS source, based on a raspberry-pi<br /> - GPS can be a simple cheap, available one.<br /> - Doesn&#039;t really need super-accurate inter-second timing, we&#039;re only going to display<br /> to the nearest second anyway.<br /> - Absolutely needs a display of some sort<br /> - Should be able to work with no network at all. If wireless is available, to do FW updates or something, bonus.<br /> - Power usage is somewhat of a concern, though could start out using wall-wart power<br /> - A big 5&quot; or 7&quot; touch display is way overkill, but could display sun location, etc, and use touch for setup<br /> - Use GPS co-ords to pick local timezone.<br /> - OLED screen and batteries?<br /> - Could we get away with solar power?<br /> - low-power mode is a goal to get us off the plug<br /> - any way we can have it turn the display off when its not light out? or when I&#039;m not looking at it? :)<br /> <br /> ==Things to Display==<br /> * Date &amp; Time in several formats:<br /> - UT1<br /> - UTC<br /> - Unix<br /> - Local<br /> - MST<br /> - AST<br /> * Number of satellites used in fix<br /> * Battery power left<br /> * Day of week (text) and month of year (text) and week of year (numeric, ISO)<br /> * Time to sunset/since sunrise<br /> * Temp/humidity/pressure<br /> * latitude/longitude<br /> * local time-zone<br /> * DST active<br /> <br /> ==Things to Adjust==<br /> * Ideally nothing, other than date/time display preferences:<br /> - 12-hour/24-hour?<br /> - ISO formatting options?<br /> - which time choices (above) to display at all times<br /> * Other localization settings &amp; options<br /> - C/F for temp<br /> - Power-saving settings?<br /> * Some way to initiate FW updates?<br /> - Would be cool if it would detect when my phone is making Wifi available, then:<br /> * connect to that<br /> * check git for FW updates (or somewhere)<br /> * check somewhere for OS and kernel updates<br /> * update itself if needed<br /> * reboot/restart app if needed<br /> <br /> ==Anything else to make available?==<br /> * Maybe a calculator? phone or laptop is more convenient, probably<br /> * Some sort of calendar mode? Again, for something like this, more than a glance, phone/laptop more convenient<br /> * Something else I could see at a glance? Home status?</div>

Admin http://sessrumnir.net/fernseher/index.php?title=GPS_clock&diff=106763 2017-03-23T21:01:49Z

<p>Admin: Created page with &quot;There are two seperate yet related goals here: * Create a local timeserver for my network, based on a GPS time-source on a raspberry-pi. - Should use a 1PPS capable GPS modu...&quot;</p> <hr /> <div>There are two seperate yet related goals here:<br /> * Create a local timeserver for my network, based on a GPS time-source on a raspberry-pi.<br /> - Should use a 1PPS capable GPS module.<br /> - Doesn&#039;t really need a display, though it can have one.<br /> - Wired networking is fine<br /> - I think it can almost entirely be based on existing packages, like gpsd, ntpd, etc.<br /> * Create a standalone clock, using a GPS source, based on a raspberry-pi<br /> - GPS can be a simple cheap, available one.<br /> - Doesn&#039;t really need super-accurate inter-second timing, we&#039;re only going to display<br /> to the nearest second anyway.<br /> - Absolutely needs a display of some sort<br /> - Should be able to work with no network at all. If wireless is available, to do FW updates or something, bonus.<br /> - Power usage is somewhat of a concern, though could start out using wall-wart power<br /> - A big 5&quot; or 7&quot; touch display is way overkill, but could display sun location, etc, and use touch for setup<br /> - Use GPS coords to pick local timezone.<br /> - OLED screen and batteries?<br /> - Could we get away with solar power?<br /> - low-power mode is a goal to get us off the plug<br /> - any way we can have it turn the display off when its not light out? or when I&#039;m not looking at it? :)<br /> <br /> Things to Display<br /> -----------------<br /> * Date &amp; Time in several formats:<br /> - UT1<br /> - UTC<br /> - Unix<br /> - Local<br /> - MST<br /> - AST<br /> * Number of satellites used in fix<br /> * Battery power left<br /> * Day of week (text) and month of year (text) and week of year (numeric, ISO)<br /> * Time to sunset/since sunrise<br /> * Temp/humidity/pressure<br /> * latitude/longitude<br /> * local time-zone<br /> * DST active<br /> <br /> Things to Adjust<br /> ----------------<br /> * Ideally nothing, other than date/time display preferences:<br /> - 12-hour/24-hour?<br /> - ISO formatting options?<br /> - which time choices (above) to display at all times<br /> * Other localization settings &amp; options<br /> - C/F for temp<br /> - Power-saving settings?<br /> * Some way to initiate FW updates?<br /> - Would be cool if it would detect when my phone is making Wifi available, then:<br /> * connect to that<br /> * check git for FW updates (or somewhere)<br /> * check somewhere for OS and kernel updates<br /> * update itself if needed<br /> * reboot/restart app if needed<br /> <br /> Anything else to make available?<br /> --------------------------------<br /> * Maybe a calculator? phone or laptop is more convenient, probably<br /> * Some sort of calendar mode? Again, for something like this, more than a glance, phone/laptop more convenient<br /> * Something else I could see at a glance? Home status?</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Fernseher&diff=106762 2017-03-23T20:49:06Z

<p>Admin: </p> <hr /> <div>Fernseher is an all encompassing set of scripts to solve all the world&#039;s problems, determine whether P really does equal NP, make me lots of money, and make a fool of myself, all at once. I imagine it will be useful to no one, do exactly what no one wants it to do, and be accused of murder and money laundering multiple times. If it does what you want it to do, reconsider, because you are probably wrong. It won&#039;t even do what I want it to do, and I wrote the damn thing.<br /> <br /> In summation, your probably don&#039;t really want this set of crap on your box, and if you put it on your box, it is likely that your computer will implode, and almost certain that all your base will belong to me.<br /> <br /> That said, I am using this wiki to keep track of ideas I have for the various components involved, what they do, what they should do, how to use them, how to improve them, and what will happen if you don&#039;t use them with everything else. I am also hoping to do some rudimentary interface design here for the various front ends, as well as backend database design so I know how its all supposed to go together. I may also put any information I have on the various utilities I plan on using to interface with the tuner cards, as well as interfaces to play music and video, adjust channels, volume, use bittorrent, etc. <br /> <br /> *Festina lente (hurry slowly)<br /> *Id est (that is)<br /> <br /> ----<br /> ===Backend/Server Components===<br /> <br /> *[[durchcoderd]]<br /> *[[herrd]]<br /> *[[rissd]]<br /> *[[seherd]]<br /> *[[unterhalterd]]<br /> <br /> ===Frontend/Client Components===<br /> <br /> *[[nackt]]<br /> *[[spieler]]<br /> *[[wunscher]]<br /> <br /> ===Database Design and Synchronization===<br /> <br /> *[[Tables]]<br /> *[[Managed Objects]]<br /> *[[Queues]]<br /> *[[Synchronization]]<br /> *[[Clients]]<br /> <br /> ===Components to Harness===<br /> <br /> *[[libgpod]]<br /> *[[vlc]]<br /> *[[mplayer]]<br /> *[[mpg123]]<br /> *[[mencoder]]<br /> *[[curses]]<br /> *[[ajax]]<br /> *[[firefox]]<br /> *[[wiimote mouse]]<br /> *[[tvshows from online]]<br /> *[http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites Auto deps for makefiles]<br /> *[http://www.fftw.org/doc/Complex-One_002dDimensional-DFTs.html fftw tutorial]<br /> *[http://en.wikipedia.org/wiki/Discrete_Fourier_transform stuff on DFT]<br /> *[http://www.grinninglizard.com/tinyxmldocs/index.html TinyXML]<br /> <br /> ===Other Related Projects===<br /> <br /> *[[bittorrent]]<br /> *[[blogging queue]]<br /> *[[mpr stream capture]]<br /> *[[photo management]]<br /> *[[email grabber]]<br /> *[[tag clouds]]<br /> *[[remote control device]]<br /> *[[dialup server system]]<br /> *[[dvdlookup.org]]<br /> *[[playlist]]<br /> *[[slackpkg plus plus]]<br /> *[[gkrellm replacement]]<br /> *[[book cataloging]]<br /> *[[some avr stuff]]<br /> *[[modjs]]<br /> *[[thoughts on avr event scheduling]]<br /> *[[MIDI and the organ project]]<br /> *[[some sess doc stuff]]<br /> *[[generic document structure objects]]<br /> *[[pennyworth]]<br /> *[[awesome keyboard]]<br /> *[[GPS clock]]<br /> ----<br /> <br /> ===Slackware resources===<br /> *slackware.com<br /> *slackbuilds.org<br /> *kernel.org<br /> *slackbook.org<br /> *slackwiki.org<br /> *sbopkg.org<br /> *linuxquestions.org<br /> *alienBOB&#039;s wiki<br /> *alienBOB&#039;s slackbuilds<br /> * ##slackware<br /> * #slackbuilds<br /> *slackware-annouce@slackware.com<br /> *slackware-security@slackware.com<br /> *slackbuilds-users@slackbuilds.org<br /> *linux-kernel@vger.kernel.org<br /> <br /> ===Stuff to get working on my computers===<br /> *[[xvmc]]<br /> *[[nis]]<br /> *[[proper dhcp]]<br /> *[[special fw on router]]<br /> *[[distributed internal network]]<br /> *[[vms to run]]</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Thoughs_on_avr_event_scheduling&diff=106761 2017-03-22T15:38:55Z

<p>Admin: Admin moved page Thoughs on avr event scheduling to Thoughts on avr event scheduling: mispelled</p> <hr /> <div>#REDIRECT [[Thoughts on avr event scheduling]]</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Thoughts_on_avr_event_scheduling&diff=106760 2017-03-22T15:38:55Z

<p>Admin: Admin moved page Thoughs on avr event scheduling to Thoughts on avr event scheduling: mispelled</p> <hr /> <div>For my reprap playground firmware, I need a better way to schedule events. This will enable me to do g-code shorthand movement calls. The general form will be<br /> int moveVect(dx, dy, dz, rampUpTime, initialSpeed, finalSpeed, rampDownTime)<br /> dx, dy, dz is the motion vector relative to current position, given in mm. rampUpTime and rampDownTime are given in seconds, and initialSpeed/finalSpeed are given in mm/s. moveVect returns 0 if we were able to move all the way to the target location. It returns 1 if we could not move all the way there because we hit an endstop. It returns 2 if we could not move all the way there because we think we would have hit another edge (no endstop).<br /> <br /> To help us, we need to have steps per mm numbers for each axis (qx, qy, qz). We also should have a stepping interval time (qt). This is how long to actually have the motor coil energized. This should either be small enough to run during the event, or large enough that a new event to de-energize can be scheduled and run.<br /> <br /> As we run through the moveVect() we determine a current speed by linearizing from 0 to initialSpeed over the rampUpTime interval, then linearizing to the finalSpeed over a calculated time it will take us to move in toto (could be tough..??), and finally linearizing back down to 0 over rampDownTime. After getting the current speed (s), we find out velocity vector (v) by normalizing the motion vector and multiplying it by the speed.<br /> dh = sqrt(dx^2 + dy^2 + dz^2)<br /> v = (dx*s/dh, dy*s/dh, dz*s/dh)<br /> <br /> The next step events should be scheduled then at times in the future given by<br /> 1/(vi*qi) - qt<br /> for each axis. This event simply steps the given axis by toggling the step line for qt seconds.<br /> <br /> Each step event needs an axis and a direction. Associated with each move is a move control block, containing velocity vector information, acceleration vector information, and target location data, as well as info about if we stopped, and why.<br /> At each event, we check endstops and position to determine if we have to stop, otherwise, we step, adjust that axis&#039;s velecity information using the acceleration information for that axis, and schedule the next event for that axis.<br /> <br /> We can chain moves together in a list, and when one move is finished (all axis event chains have ceased, or we are on the last one), we pull up the next move control block and trigger its event chains for each axis.<br /> <br /> We&#039;ll need to use one of the chip&#039;s timers for our interrupt, and the interrupt should look at the next event in the event list, and if its timer has expired or will expire, we execute it and remove it from the list. We then look at the next event in the list. If its timer has now expired, we execute that one too. We keep doing this until we have no more events or we find one that needs to execute in the future. We set our interrupt for that future time and exit.<br /> <br /> When somebody schedules a new event, we determine if the new event should fire after or before the first one in our current list. If before, we put it in the list before the first item and reset the interrupt trigger time to our new event&#039;s time. If after, we put it in the list in the right spot and call it good.<br /> <br /> Scheduling an event and the checking to see if we need to run an event need to occur under an event list lock, so we don&#039;t mess up our event list or the timer. Just use a spin lock probably, and enable/disable interrupts around our check and set.<br /> <br /> == Move List ==<br /> move list lock, next move ptr, next available id, plus list of move control blocks, each containing:<br /> type = 1(move)<br /> id<br /> status 0 not yet active, 1 in progress, 2 complete, at target, 3 complete, not at target<br /> link to next move<br /> x,y,z endstop/position status (0, ok, 1 max endstop, 2 min endstop, 3 max steps, 4 min steps)<br /> x,y,z target<br /> x,y,z velocity (current)<br /> x,y,z acceleration<br /> link to next move<br /> <br /> type = 2(dwell)<br /> id<br /> status 0 not yet active, 1 in progress, 2 completed.<br /> link to next move<br /> dwell time<br /> <br /> When a move is completed, the old move control block is left on the list until it is removed (to check status, etc), but the next move in the list is started up immediately. Some move functions:<br /> mid = moveDelta(dx, dy, dz, initial speed, final speed)<br /> mid = moveTo(x, y, z, initial speed, final speed)<br /> status = cancelMove(mid)<br /> mid = moveDwell(dwell time)<br /> void genMcb(delta?, x,y,z, ispeed, fspeed, buffer*)<br /> <br /> == Event Queue ==<br /> event queue lock, next event ptr, next available id, plus list of event control blocks currently scheduled<br /> type = 0 nop<br /> time to fire<br /> id<br /> link to next event<br /> move after?<br /> <br /> type = 1 step<br /> time to fire<br /> id<br /> link to next event<br /> axis<br /> move control block ptr<br /> <br /> type = 2 run<br /> time to fire<br /> id<br /> link to next event<br /> function ptr to call (of type (void)(void*))<br /> ptr to pass to function when run<br /> <br /> type = 3 move<br /> time to fire<br /> id<br /> link to next event<br /> number of mcbs in this event<br /> move control blocks to run in the future<br /> <br /> When an event is triggered, the event is discarded after being run. Some event functions:<br /> eid = scheduleEvent(type, delta time, data ptr, data len) (eid = -1 means couldn&#039;t schedule)<br /> status = cancelEvent(eid) (status = -1 means no such event)<br /> eid = scheduleFunction(delta time, func ptr, data)<br /> eid = scheduleMoveSequence(delta time, num moves, mcb*)<br /> eid = scheduleNop(delta time, move after?)</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Fernseher&diff=106759 2017-03-21T23:21:09Z

<p>Admin: revert</p> <hr /> <div>Fernseher is an all encompassing set of scripts to solve all the world&#039;s problems, determine whether P really does equal NP, make me lots of money, and make a fool of myself, all at once. I imagine it will be useful to no one, do exactly what no one wants it to do, and be accused of murder and money laundering multiple times. If it does what you want it to do, reconsider, because you are probably wrong. It won&#039;t even do what I want it to do, and I wrote the damn thing.<br /> <br /> In summation, your probably don&#039;t really want this set of crap on your box, and if you put it on your box, it is likely that your computer will implode, and almost certain that all your base will belong to me.<br /> <br /> That said, I am using this wiki to keep track of ideas I have for the various components involved, what they do, what they should do, how to use them, how to improve them, and what will happen if you don&#039;t use them with everything else. I am also hoping to do some rudimentary interface design here for the various front ends, as well as backend database design so I know how its all supposed to go together. I may also put any information I have on the various utilities I plan on using to interface with the tuner cards, as well as interfaces to play music and video, adjust channels, volume, use bittorrent, etc. <br /> <br /> *Festina lente (hurry slowly)<br /> *Id est (that is)<br /> <br /> ----<br /> ===Backend/Server Components===<br /> <br /> *[[durchcoderd]]<br /> *[[herrd]]<br /> *[[rissd]]<br /> *[[seherd]]<br /> *[[unterhalterd]]<br /> <br /> ===Frontend/Client Components===<br /> <br /> *[[nackt]]<br /> *[[spieler]]<br /> *[[wunscher]]<br /> <br /> ===Database Design and Synchronization===<br /> <br /> *[[Tables]]<br /> *[[Managed Objects]]<br /> *[[Queues]]<br /> *[[Synchronization]]<br /> *[[Clients]]<br /> <br /> ===Components to Harness===<br /> <br /> *[[libgpod]]<br /> *[[vlc]]<br /> *[[mplayer]]<br /> *[[mpg123]]<br /> *[[mencoder]]<br /> *[[curses]]<br /> *[[ajax]]<br /> *[[firefox]]<br /> *[[wiimote mouse]]<br /> *[[tvshows from online]]<br /> *[http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites Auto deps for makefiles]<br /> *[http://www.fftw.org/doc/Complex-One_002dDimensional-DFTs.html fftw tutorial]<br /> *[http://en.wikipedia.org/wiki/Discrete_Fourier_transform stuff on DFT]<br /> *[http://www.grinninglizard.com/tinyxmldocs/index.html TinyXML]<br /> <br /> ===Other Related Projects===<br /> <br /> *[[bittorrent]]<br /> *[[blogging queue]]<br /> *[[mpr stream capture]]<br /> *[[photo management]]<br /> *[[email grabber]]<br /> *[[tag clouds]]<br /> *[[remote control device]]<br /> *[[dialup server system]]<br /> *[[dvdlookup.org]]<br /> *[[playlist]]<br /> *[[slackpkg plus plus]]<br /> *[[gkrellm replacement]]<br /> *[[book cataloging]]<br /> *[[some avr stuff]]<br /> *[[modjs]]<br /> *[[thoughts on avr event scheduling]]<br /> *[[MIDI and the organ project]]<br /> *[[some sess doc stuff]]<br /> *[[generic document structure objects]]<br /> *[[pennyworth]]<br /> *[[awesome keyboard]]<br /> ----<br /> <br /> ===Slackware resources===<br /> *slackware.com<br /> *slackbuilds.org<br /> *kernel.org<br /> *slackbook.org<br /> *slackwiki.org<br /> *sbopkg.org<br /> *linuxquestions.org<br /> *alienBOB&#039;s wiki<br /> *alienBOB&#039;s slackbuilds<br /> * ##slackware<br /> * #slackbuilds<br /> *slackware-annouce@slackware.com<br /> *slackware-security@slackware.com<br /> *slackbuilds-users@slackbuilds.org<br /> *linux-kernel@vger.kernel.org<br /> <br /> ===Stuff to get working on my computers===<br /> *[[xvmc]]<br /> *[[nis]]<br /> *[[proper dhcp]]<br /> *[[special fw on router]]<br /> *[[distributed internal network]]<br /> *[[vms to run]]</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Fernseher&diff=106758 2017-03-21T23:16:11Z

<p>Admin: Reverted edits by CerysVogel (talk) to last revision by BrookeV67cwkq</p> <hr /> <div>拉直板是很多女性朋友家居生活中常用的美发工具，只要使用来把头发弄卷进行造型的，那拉直板什么牌子好? [http://www.ghgvip.com GHG curl secret] 卷发器怎么选购?我们了解下：&lt;br&gt;&lt;br&gt;卷发器什么牌子好?&lt;br&gt;&lt;br&gt;　　1、沙宣VS(1954年创立于英国,美发工具产业璀璨明星,在顾客和市场上享有盛誉,宝洁公司授权美康雅国际贸易有限公司)&lt;br&gt;　　2、飞利浦PHILIPS(始创于1891年荷兰,世界上最大的电子公司之一,全球100个最具价值品牌,飞利浦电子(中国)投资有限公司)&lt;br&gt;　　3、松下Panasonic(于1918年日本,世界500强企业,世界品牌,大型跨国公司,全球最大的电子厂商之一,松下电器(中国)有限公司)&lt;br&gt;　　4、GHG(创立于美国,世界著名直发器卷发器品牌,享有极高声誉的拉直板品牌,深受造型师推崇的美发工具品牌,美国GHG公司)&lt;br&gt;　　5、博朗BRAUN(始创于1921年德国,宝洁公司旗下,小家电行业著名品牌,大型跨国集团,欧美高端市场品牌,德国博朗有限公司)&lt;br&gt;　　6、奔腾POVOS(上海市著名商标,高新技术企业,十大美发工具品牌,个人护理电器行业领先品牌,上海奔腾企业(集团)有限公司)&lt;br&gt;　　7、BaByliss PRO(创于1961年,全球专业美发造型工具生产制造商,欧洲顶级沙龙用美发工具品牌,美康雅国际贸易有限公司)&lt;br&gt;　　8、飞科FLYCO(上海市著名商标,参与剃须刀行业国家标准制订,集剃须刀及小家电研发制造销售的企业,浙江飞科集团有限公司)&lt;br&gt;　　9、康夫(广东省著名商标,集开发/设计/生产/营销于一体的电器企业,知名美发工具品牌,广东华能达电器有限公司)&lt;br&gt;　　10、谭木匠(上市公司,国内木质梳理用品行业领军品牌,最具价值品牌之一,拥有多项专利技术,谭木匠控股有限公司)&lt;br&gt;&lt;br&gt;家用卷发器的选购方法：&lt;br&gt;&lt;br&gt;　　1、品牌：&lt;br&gt;　　目前市场上在售的家用卷发器品牌很多，价格从几十元到上千元不等。在选购时建议大家尽量选购大厂生产的名牌产品，并且注意一下产品的外包装是否注明生产厂家、产品型号等具体信息，避免选购到质量低劣的假冒产品。&lt;br&gt;&lt;br&gt;　　2、外观：&lt;br&gt;　　无论选购哪个品牌的卷发器，检查产品外观都是必要的一个步骤。首先，直板夹的外观造型应该时尚小巧、易于抓握;另外，外观各个部件应该造型规整、接缝均匀紧密;第三，还要留意一下直发器的重量，通常质量较好的自动卷发器都会相对重一些。&lt;br&gt;&lt;br&gt;　　3、材质：&lt;br&gt;　　观察自动卷发器关键部位的材质也是选购直发器的重要环节。建议大家选购卷发器表面为陶瓷釉面、陶瓷釉面光洁的优质产品，此类产品不但使用起来光滑顺洁、而且使用寿命长、易于打理。&lt;br&gt;&lt;br&gt;　　直发器品牌及选购方法就和大家分享到这里了，希望能帮到大家，更多信息请继续关注我们。</div>

Admin http://sessrumnir.net/fernseher/index.php?title=MIDI_and_the_organ_project&diff=106757 2017-03-21T23:02:31Z

<p>Admin: </p> <hr /> <div>*[http://sessrumnir.net/organs/trunk/ SVN trunk for organ code]<br /> *[http://www.die-orgelseite.de/pfeifenarten_e.htm Interesting site for pipe shapes and sounds]<br /> <br /> *[[Pipe creation workflow]]<br /> *[[Theoretical Pipe Variations]]<br /> *[[Spectra]]<br /> *[[Other stuff]]<br /> <br /> <br /> ====MIDI and the organ====<br /> MIDI standard is out there. Also good is the RTP-MIDI RFC, for putting MIDI data into a stream and whatnot.<br /> <br /> The basics, as I think we will be using them:<br /> <br /> Packet basics (we&#039;ll only be using 3 byte packet forms):<br /> <br /> 1 &lt;3: opcode&gt; &lt;4: channel&gt; 0 &lt;7: arg1&gt; 0 &lt;7: arg2&gt;<br /> <br /> Essentially, a status byte, with the high bit on (0x80-0xFF), and two argument bytes, with the high bit off (0x00-0x7F).<br /> <br /> opcodes of relevance:<br /> *0x0: key off. arg1 is the key number, arg2 is the velocity. We will always use velocity of 0x40.<br /> *0x1: key on. arg1 is the key number, arg2 is the velocity. We will always use the velocity of 0x40.<br /> *0x3: control change. arg1 is the control number (0x01 is modulation wheel, 0x0B is the expression pedal), arg2 is the new control value, from 0x00 - 0x7F (Note: If we need more than 127 steps, add 0x20 to the control number, and thats the control number to use to send the least significant 7-bits of the value. The value sent with the base control number is considered to be the most significant 7-bits of the value. This ensures that if just read the base control number, you set the control to approximately the correct percentage of fully off/fully on.)<br /> <br /> For channels, we will use:<br /> *0x0: Great (Solo) Manual<br /> *0x1: Swell (Accompaniment) Manual<br /> *0x2: Choir (below Great) Manual, if present<br /> *0x3: Solo (above Swell) Manual, if present<br /> *0x4: Echo (above Solo) Manual, if present<br /> *0x5: Third Pedalboard, if present, or the auxilary stop channel, covering additional stops for all manuals and pedals.<br /> *0x6: Second Pedalboard, if present, or the main stop channel, covering all stops for all manuals and pedals.<br /> *0x7: Main Pedalboard<br /> *0x8: Great stops only<br /> *0x9: Swell stops only<br /> *0xA: Choir stops only<br /> *0xB: Solo stops only<br /> *0xC: Echo stops only<br /> *0xD: Third Pedalboard stops only<br /> *0xE: Second Pedalboard stops only<br /> *0xF: Main Pedalboard stops only<br /> <br /> Our initial organ will only use channels 0x0-0x1, 0x6-0x7.<br /> <br /> Each keyboard channel (0x0-0x7) gets its own control set. For our organ, where the modulation wheel and expression pedal control all divisions equally, each control change gets sent for each active channel... or maybe just for great, and the software will figure out that they control all the stuff. Note, we may not hook up the modulation wheel when we begin. It&#039;d be kinda a lot harder to make work right, I think.<br /> <br /> We will be building channel combination boards, that take an enable and a sub-channel address, and read back the contents of the addressed buffer. 4 bits of address gets 16 buffers. At 8 bits per buffer, thats 128 inputs for each channel. That matches with midi&#039;s numbering scheme. Alternatively, if you take the LSB of the true channel, and feed it to the 4th address bit of the channel board, and only decode the top 3 bits of the channel to determine channel board enable, you can duplex your channel boards, since we will only be using under 64 inputs per channel. The AVR firmware will have an MIDI offset value for each channel to add to the number received from the board before sending as part of a MIDI command. For most subchannels, this will be 36. Will probably just use an offset of 0 for the stop channels.<br /> <br /> Using the split channel board design, we only need two channel boards for our organ. The main board will be designed to use the channel boards in split mode, and will never probably use the split-mode stop channels (0x8-0xF), so it will only have 4 plugs for channel boards, 0x0-0x1, 0x2-0x3, 0x4-0x5, and 0x6-0x7. The initial organ will only use the first and last of these plugs, so we don&#039;t even need to populate the board positions for the other channel boards.<br /> <br /> Also, I think we might want to put all the switch pull-up resistors on the manuals themselves, soldered to the key tabs. This will eliminate a lot of crap on the boards, and keep the board design uniform, since the different keys will need different pull-ups. The manuals, with their 5k internal resistance, will need 50k (or so) pull-ups to 5V, and the pedals and stops, with no internal resistance, will need just 10k (or so) pull-ups to 5V. Each manual will get a separate power and ground plug for the pull-ups and grounds, so the connectors for the keys don&#039;t need a pin for ground or power, I don&#039;t think... Though if there is room, I guess we could send it along there, too. Can&#039;t hurt anything, provided the wires support enough current for the crazy case of all the stop pulled or keys pressed or something. Given a max of 64 inputs to a half-channel, and only 61 keys on a full manual, we can use 2x36 pin connectors for the manuals, and 1x36 pin connector for the pedalboards, and 1x36 pin connector for the stop boards. Thats 6 total 36 pin connectors, male and female, solder cup and through-hole.<br /> <br /> Channel board to main board connectors will have an 8-bit data bus, 4-bit address bus, a power, ground, enable, and identify(?) pins (16 total). Should be able to use IDC connectors and ribbon cable here.<br /> <br /> ===Simple algorithm for key change detection===<br /> After reading a byte from the buffers, we xor it with the copy of the byte from last time, then store the new version in the copy location. We then start looking at the lsb of the xor&#039;ed byte. If its a 1, we send a key on if the lsb of the read byte is a 1, and a key off if the lsb of the read byte is a 0. We then shift right and do that again. We do that 8 times, once for each bit in that byte. Then we can move on to the next valid address for that channel, write out the address, read back the buffer value, xor, store, analyze, etc. Note, we can speed this up by checking if the xor byte is identically 0x00, in which case we don&#039;t have to analyze it, it hasn&#039;t changed. This will be the usual case! Only occasionally (in sample time), will things change, and usually only on one bit, and thus one buffer, amongst all the channels and buffers. This should help us keep up to speed.<br /> <br /> Once we are done reading all the channel board buffers, we can check the expression pedals and other variable controls for new values, and possibly send control change events. After all this, we actually send the MIDI bytes as we have determined them to need to be for this time around, and go to sleep until our next sample time.<br /> <br /> Not sure what the latency of the serial to USB conversion is in FTDI, but it could be as bad as a single byte in a single USB message.... Anyway, we want to build a buffer of bytes that need to get send over each sample time, with the RTP-MIDI spec used to make it a stream type thing. This means: packet length, &quot;timestamp&quot;, first MIDI event, relative timestamps (should all be zero), subsequent MIDI events.<br /> <br /> ===Chips to use===<br /> *16x? 74HCT540 for the octal tri-state buffers, inverting (0.54, 20 pin dip)<br /> *1x? 74HCT138 for 1 to 8 decoder (0.40, 16 pin dip)<br /> *1x? 74HCT154 for 1 to 16 decoder (0.80, 24 pin dip)<br /> *1x ATMega164P-20P for AVR controller, 20MHz, (4.82, 40 pin dip)<br /> <br /> <br /> ===Stuff from the old Google Notebook stuff===<br /> ====Pin layout====<br /> *8 data (D7-D0)<br /> *8 address (A7-A0)<br /> *5 inverted address (/A7-/A3)<br /> *1 power (V)<br /> *1 ground (G)<br /> *1 card select (S)<br /> *1 R/W (R)<br /> *1 Presence detect (P)<br /> 1 2 3 4 5 6 7 8 9 10 11 12 13<br /> 1 V S R P G A0-------A2 A3--------------A7<br /> 2 D0---------------Data--------D7 /A3------------/A7<br /> <br /> ====Alternative Input Detection====<br /> Using 40pin AVR, we can use a lot of digital inputs directly to the AVR. We have to use some for normal things. On the slave:<br /> *Vcc<br /> *Gnd<br /> *Reset<br /> *XTAL1<br /> *XTAL2<br /> *UART RX (all tied to CNTR TX)<br /> *UART TX (all tied to MIDI out + CNTR RX)<br /> *RTS<br /> *CTS<br /> Thats 9 pins, so 31 are left for digital inputs for keys/stops (per controller).<br /> <br /> On the master (CNTR):<br /> *Vcc<br /> *Gnd<br /> *Reset<br /> *XTAL1<br /> *XTAL2<br /> *UART1 RX (tied to all Slave TXs)<br /> *UART1 TX (tied to all Slave RXs)<br /> *MOSI<br /> *MISO<br /> *SCK<br /> *UART2 RX (from host)<br /> *UART2 TX (to host)<br /> Thats 12 pins, so 28 are left for RTS/CTS controls for each slave. That means a max of 14 slaves. However, if we use some ADCs on the master for analog controls, we might lose some possible slaves. Or, the analog controls could be fed to a slave controller, or a dedicated controller.<br /> <br /> If we have what you might hope would be a max config:<br /> *5 manuals@61 keys is 2 slaves/manual, or 10 max<br /> *1 pedalboard@30/32 keys is 1 slaves/pedalboard, or 1 max (Note: 32 wouldn&#039;t fit...)<br /> *1 set of stops@60 stops or so is 2 slaves/stop set, or 2 max<br /> That gives us about 13 boards. Maybe the last slave could be used for more stops, or analog controls.</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Fernseher&diff=106646 2014-09-22T01:07:35Z

<p>Admin: </p> <hr /> <div>Fernseher is an all encompassing set of scripts to solve all the world&#039;s problems, determine whether P really does equal NP, make me lots of money, and make a fool of myself, all at once. I imagine it will be useful to no one, do exactly what no one wants it to do, and be accused of murder and money laundering multiple times. If it does what you want it to do, reconsider, because you are probably wrong. It won&#039;t even do what I want it to do, and I wrote the damn thing.<br /> <br /> In summation, your probably don&#039;t really want this set of crap on your box, and if you put it on your box, it is likely that your computer will implode, and almost certain that all your base will belong to me.<br /> <br /> That said, I am using this wiki to keep track of ideas I have for the various components involved, what they do, what they should do, how to use them, how to improve them, and what will happen if you don&#039;t use them with everything else. I am also hoping to do some rudimentary interface design here for the various front ends, as well as backend database design so I know how its all supposed to go together. I may also put any information I have on the various utilities I plan on using to interface with the tuner cards, as well as interfaces to play music and video, adjust channels, volume, use bittorrent, etc. <br /> <br /> *Festina lente (hurry slowly)<br /> *Id est (that is)<br /> <br /> ----<br /> ===Backend/Server Components===<br /> <br /> *[[durchcoderd]]<br /> *[[herrd]]<br /> *[[rissd]]<br /> *[[seherd]]<br /> *[[unterhalterd]]<br /> <br /> ===Frontend/Client Components===<br /> <br /> *[[nackt]]<br /> *[[spieler]]<br /> *[[wunscher]]<br /> <br /> ===Database Design and Synchronization===<br /> <br /> *[[Tables]]<br /> *[[Managed Objects]]<br /> *[[Queues]]<br /> *[[Synchronization]]<br /> *[[Clients]]<br /> <br /> ===Components to Harness===<br /> <br /> *[[libgpod]]<br /> *[[vlc]]<br /> *[[mplayer]]<br /> *[[mpg123]]<br /> *[[mencoder]]<br /> *[[curses]]<br /> *[[ajax]]<br /> *[[firefox]]<br /> *[[wiimote mouse]]<br /> *[[tvshows from online]]<br /> *[http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites Auto deps for makefiles]<br /> *[http://www.fftw.org/doc/Complex-One_002dDimensional-DFTs.html fftw tutorial]<br /> *[http://en.wikipedia.org/wiki/Discrete_Fourier_transform stuff on DFT]<br /> *[http://www.grinninglizard.com/tinyxmldocs/index.html TinyXML]<br /> <br /> ===Other Related Projects===<br /> <br /> *[[bittorrent]]<br /> *[[blogging queue]]<br /> *[[mpr stream capture]]<br /> *[[photo management]]<br /> *[[email grabber]]<br /> *[[tag clouds]]<br /> *[[remote control device]]<br /> *[[dialup server system]]<br /> *[[dvdlookup.org]]<br /> *[[playlist]]<br /> *[[slackpkg plus plus]]<br /> *[[gkrellm replacement]]<br /> *[[book cataloging]]<br /> *[[some avr stuff]]<br /> *[[modjs]]<br /> *[[thoughts on avr event scheduling]]<br /> *[[MIDI and the organ project]]<br /> *[[some sess doc stuff]]<br /> *[[generic document structure objects]]<br /> *[[pennyworth]]<br /> *[[awesome keyboard]]<br /> ----<br /> <br /> ===Slackware resources===<br /> *slackware.com<br /> *slackbuilds.org<br /> *kernel.org<br /> *slackbook.org<br /> *slackwiki.org<br /> *sbopkg.org<br /> *linuxquestions.org<br /> *alienBOB&#039;s wiki<br /> *alienBOB&#039;s slackbuilds<br /> * ##slackware<br /> * #slackbuilds<br /> *slackware-annouce@slackware.com<br /> *slackware-security@slackware.com<br /> *slackbuilds-users@slackbuilds.org<br /> *linux-kernel@vger.kernel.org<br /> <br /> ===Stuff to get working on my computers===<br /> *[[xvmc]]<br /> *[[nis]]<br /> *[[proper dhcp]]<br /> *[[special fw on router]]<br /> *[[distributed internal network]]<br /> *[[vms to run]]</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Fernseher&diff=106494 2014-09-22T00:44:38Z

<p>Admin: </p> <hr /> <div>Fernseher is an all encompassing set of scripts to solve all the world&#039;s problems, determine whether P really does equal NP, make me lots of money, and make a fool of myself, all at once. I imagine it will be useful to no one, do exactly what no one wants it to do, and be accused of murder and money laundering multiple times. If it does what you want it to do, reconsider, because you are probably wrong. It won&#039;t even do what I want it to do, and I wrote the damn thing.<br /> <br /> In summation, your probably don&#039;t really want this set of crap on your box, and if you put it on your box, it is likely that your computer will implode, and almost certain that all your base will belong to me.<br /> <br /> That said, I am using this wiki to keep track of ideas I have for the various components involved, what they do, what they should do, how to use them, how to improve them, and what will happen if you don&#039;t use them with everything else. I am also hoping to do some rudimentary interface design here for the various front ends, as well as backend database design so I know how its all supposed to go together. I may also put any information I have on the various utilities I plan on using to interface with the tuner cards, as well as interfaces to play music and video, adjust channels, volume, use bittorrent, etc. <br /> <br /> *Festina lente (hurry slowly)<br /> *Id est (that is)<br /> <br /> ----<br /> ===Backend/Server Components===<br /> <br /> *[[durchcoderd]]<br /> *[[herrd]]<br /> *[[rissd]]<br /> *[[seherd]]<br /> *[[unterhalterd]]<br /> <br /> ===Frontend/Client Components===<br /> <br /> *[[nackt]]<br /> *[[spieler]]<br /> *[[wunscher]]<br /> <br /> ===Database Design and Synchronization===<br /> <br /> *[[Tables]]<br /> *[[Managed Objects]]<br /> *[[Queues]]<br /> *[[Synchronization]]<br /> *[[Clients]]<br /> <br /> ===Components to Harness===<br /> <br /> *[[libgpod]]<br /> *[[vlc]]<br /> *[[mplayer]]<br /> *[[mpg123]]<br /> *[[mencoder]]<br /> *[[curses]]<br /> *[[ajax]]<br /> *[[firefox]]<br /> *[[wiimote mouse]]<br /> *[[tvshows from online]]<br /> *[http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites Auto deps for makefiles]<br /> *[http://www.fftw.org/doc/Complex-One_002dDimensional-DFTs.html fftw tutorial]<br /> *[http://en.wikipedia.org/wiki/Discrete_Fourier_transform stuff on DFT]<br /> *[http://www.grinninglizard.com/tinyxmldocs/index.html TinyXML]<br /> <br /> ===Other Related Projects===<br /> <br /> *[[bittorrent]]<br /> *[[blogging queue]]<br /> *[[mpr stream capture]]<br /> *[[photo management]]<br /> *[[email grabber]]<br /> *[[tag clouds]]<br /> *[[remote control device]]<br /> *[[dialup server system]]<br /> *[[dvdlookup.org]]<br /> *[[playlist]]<br /> *[[slackpkg plus plus]]<br /> *[[gkrellm replacement]]<br /> *[[book cataloging]]<br /> *[[some avr stuff]]<br /> *[[modjs]]<br /> *[[thoughts on avr event scheduling]]<br /> *[[MIDI and the organ project]]<br /> *[[some sess doc stuff]]<br /> *[[generic document structure objects]]<br /> *[[pennyworth]]<br /> *[[awesome keyboard]]<br /> ----<br /> <br /> ===Slackware resources===<br /> *slackware.com<br /> *slackbuilds.org<br /> *kernel.org<br /> *slackbook.org<br /> *slackwiki.org<br /> *sbopkg.org<br /> *linuxquestions.org<br /> *alienBOB&#039;s wiki<br /> *alienBOB&#039;s slackbuilds<br /> * ##slackware<br /> * #slackbuilds<br /> *slackware-annouce@slackware.com<br /> *slackware-security@slackware.com<br /> *slackbuilds-users@slackbuilds.org<br /> *linux-kernel@vger.kernel.org<br /> <br /> ===Stuff to get working on my computers===<br /> *[[xvmc]]<br /> *[[nis]]<br /> *[[proper dhcp]]<br /> *[[special fw on router]]<br /> *[[distributed internal network]]<br /> *[[vms to run]]</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Vms_to_run&diff=2169 2011-03-16T22:44:04Z

<p>Admin: Created page with &#039;===Client Hosts=== External hosts (coming in through external network) *work laptop at work *web clients *friends externally trying to access friend mirror services/distributed s…&#039;</p> <hr /> <div>===Client Hosts===<br /> External hosts (coming in through external network)<br /> *work laptop at work<br /> *web clients<br /> *friends externally trying to access friend mirror services/distributed storage<br /> <br /> Guest hosts<br /> *friends that come over, etc. (laptops, phones, tablets)<br /> <br /> portable hosts<br /> *my phones<br /> *my pdas<br /> *my wii?<br /> *my tablets<br /> *my ereaders<br /> *my ipods<br /> <br /> laptop hosts<br /> *normal laptop<br /> *work laptop at home<br /> *shop laptop<br /> <br /> media player hosts<br /> *living room (video+music)<br /> *library (video+music)<br /> *shop (music)<br /> *bedroom (music) <br /> <br /> controller hosts<br /> *extremely limited purpose devices on the network to control one thing (such as hydroponics, or thermostat stuff)<br /> <br /> <br /> ===Server Hosts===<br /> *file serving (nfs)<br /> *network services (nis, dhcp, boot images, routing, config data)<br /> *house control/monitoring (webcams, internal/external environment sense, thermostat, garage door control/sense, sump pump sense, computer temps/stats, external rain barrel control)<br /> *media streaming (vlc and mpd)<br /> *printer/scanner/reprap<br /> *internal mysql<br /> *internal web<br /> *internal svn<br /> *external mysql<br /> *external web<br /> *external svn<br /> *external mirrors (kernels, slackware, slackbuilds, alienbob, package sources)<br /> *slackware current testing<br /> *slackware package testing<br /> *friend mirrors<br /> *friend shared media<br /> *transcode, compile, and processing server<br /> <br /> <br /> <br /> ===Networks===<br /> *external<br /> **internet, mostly untrusted. routed to external stuff, friend mirrors/shared media, and (if trusted) printer stuff, media streaming, and house control.<br /> *modem to gateway<br /> **not really used, but its there. actually might include the charter upstream port as well?<br /> **internal dmz network<br /> **network used to expose extern<br /> *internal infrastructure network<br /> **network used internally for flows that should just happen behind the scenes that me as a user never really needs to access directly (only through an external physical device interface, or some proxy webpage or something)<br /> *internal usage network<br /> **my laptops, allowing access to internal services where needed, but not more than that<br /> *guest internal network<br /> **when friends come over<br /> **my own portable devices</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Fernseher&diff=2168 2011-03-16T22:35:16Z

<p>Admin: </p> <hr /> <div>Fernseher is an all encompassing set of scripts to solve all the world&#039;s problems, determine whether P really does equal NP, make me lots of money, and make a fool of myself, all at once. I imagine it will be useful to no one, do exactly what no one wants it to do, and be accused of murder and money laundering multiple times. If it does what you want it to do, reconsider, because you are probably wrong. It won&#039;t even do what I want it to do, and I wrote the damn thing.<br /> <br /> In summation, your probably don&#039;t really want this set of crap on your box, and if you put it on your box, it is likely that your computer will implode, and almost certain that all your base will belong to me.<br /> <br /> That said, I am using this wiki to keep track of ideas I have for the various components involved, what they do, what they should do, how to use them, how to improve them, and what will happen if you don&#039;t use them with everything else. I am also hoping to do some rudimentary interface design here for the various front ends, as well as backend database design so I know how its all supposed to go together. I may also put any information I have on the various utilities I plan on using to interface with the tuner cards, as well as interfaces to play music and video, adjust channels, volume, use bittorrent, etc. <br /> <br /> *Festina lente (hurry slowly)<br /> *Id est (that is)<br /> <br /> ----<br /> ===Backend/Server Components===<br /> <br /> *[[durchcoderd]]<br /> *[[herrd]]<br /> *[[rissd]]<br /> *[[seherd]]<br /> *[[unterhalterd]]<br /> <br /> ===Frontend/Client Components===<br /> <br /> *[[nackt]]<br /> *[[spieler]]<br /> *[[wunscher]]<br /> <br /> ===Database Design and Synchronization===<br /> <br /> *[[Tables]]<br /> *[[Managed Objects]]<br /> *[[Queues]]<br /> *[[Synchronization]]<br /> *[[Clients]]<br /> <br /> ===Components to Harness===<br /> <br /> *[[libgpod]]<br /> *[[vlc]]<br /> *[[mplayer]]<br /> *[[mpg123]]<br /> *[[mencoder]]<br /> *[[curses]]<br /> *[[ajax]]<br /> *[[firefox]]<br /> *[[wiimote mouse]]<br /> *[[tvshows from online]]<br /> *[http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites Auto deps for makefiles]<br /> *[http://www.fftw.org/doc/Complex-One_002dDimensional-DFTs.html fftw tutorial]<br /> *[http://en.wikipedia.org/wiki/Discrete_Fourier_transform stuff on DFT]<br /> *[http://www.grinninglizard.com/tinyxmldocs/index.html TinyXML]<br /> <br /> ===Other Related Projects===<br /> <br /> *[[bittorrent]]<br /> *[[blogging queue]]<br /> *[[mpr stream capture]]<br /> *[[photo management]]<br /> *[[email grabber]]<br /> *[[tag clouds]]<br /> *[[remote control device]]<br /> *[[dialup server system]]<br /> *[[dvdlookup.org]]<br /> *[[playlist]]<br /> *[[slackpkg plus plus]]<br /> *[[gkrellm replacement]]<br /> *[[book cataloging]]<br /> *[[some avr stuff]]<br /> *[[modjs]]<br /> *[[thoughts on avr event scheduling]]<br /> *[[MIDI and the organ project]]<br /> *[[some sess doc stuff]]<br /> *[[generic document structure objects]]<br /> *[[pennyworth]]<br /> *[[awesome keyboard]]<br /> ----<br /> <br /> ===Slackware resources===<br /> *slackware.com<br /> *slackbuilds.org<br /> *kernel.org<br /> *slackbook.org<br /> *slackwiki.org<br /> *sbopkg.org<br /> *linuxquestions.org<br /> *alienBOB&#039;s wiki<br /> *alienBOB&#039;s slackbuilds<br /> * ##slackware<br /> * #slackbuilds<br /> *slackware-annouce@slackware.com<br /> *slackware-security@slackware.com<br /> *slackbuilds-users@slackbuilds.org<br /> *linux-kernel@vger.kernel.org<br /> <br /> ===Stuff to get working on my computers===<br /> *[[xvmc]]<br /> *[[nis]]<br /> *[[proper dhcp]]<br /> *[[special fw on router]]<br /> *[[distributed internal network]]<br /> *[[vms to run]]</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Awesome_keyboard&diff=2167 2011-03-16T22:33:08Z

<p>Admin: Created page with &#039;New keyboard kinda based on old space-cadet type keyboards: Each letter key has several shiftables: base letter, shift+letter (capitalization), front+letter (greek, etc), front…&#039;</p> <hr /> <div>New keyboard kinda based on old space-cadet type keyboards:<br /> <br /> Each letter key has several shiftables: base letter, shift+letter (capitalization), front+letter (greek, etc), front+shift+letter (capital greek, etc), top+letter<br /> <br /> Bucky bit keys: control, meta, hyper, super (alt, esc, menu?)<br /> <br /> Perhaps some compose type key?<br /> Perhaps some generic unicode numeric key? Maybe some common actual unicode keys?<br /> <br /> Maybe the bucky bit keys can be organ type pedals?<br /> <br /> Be sure to include a numeric keypad (always in numlock mode) with hexadecimal digits A-F included.<br /> Probably don&#039;t need PrtSc, SysRq, Pause, Break, ScrollLock, NumLock<br /> <br /> Function keys can stay, I guess. Though I probably won&#039;t use them much.<br /> <br /> Can I use both the keyboard/keypad HID stuff as well as the unicode HID stuff?<br /> <br /> Perhaps map the Ctrl/alt/shift/menu keys to always be left hand side keys, then use the right hand side keys to mean the new stuff: front, top, meta, hyper, super (may not be able to fit all of these...)<br /> <br /> In unicode mode, the none, shift, front, top, ctrl, esc can directly use the unicode equivalents (ctrl uses C0, esc uses C1) Not sure what to do here with alt, menu, meta, hyper, and super. Maybe some user defined Cx area? If so, make sure there is room for extra ctrl/esc with all my extra letters, as well as shifted fronted, topped versions and combinations of everything? Wow.</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Fernseher&diff=2166 2011-03-16T22:32:02Z

<p>Admin: /* Other Related Projects */</p> <hr /> <div>Fernseher is an all encompassing set of scripts to solve all the world&#039;s problems, determine whether P really does equal NP, make me lots of money, and make a fool of myself, all at once. I imagine it will be useful to no one, do exactly what no one wants it to do, and be accused of murder and money laundering multiple times. If it does what you want it to do, reconsider, because you are probably wrong. It won&#039;t even do what I want it to do, and I wrote the damn thing.<br /> <br /> In summation, your probably don&#039;t really want this set of crap on your box, and if you put it on your box, it is likely that your computer will implode, and almost certain that all your base will belong to me.<br /> <br /> That said, I am using this wiki to keep track of ideas I have for the various components involved, what they do, what they should do, how to use them, how to improve them, and what will happen if you don&#039;t use them with everything else. I am also hoping to do some rudimentary interface design here for the various front ends, as well as backend database design so I know how its all supposed to go together. I may also put any information I have on the various utilities I plan on using to interface with the tuner cards, as well as interfaces to play music and video, adjust channels, volume, use bittorrent, etc. <br /> <br /> *Festina lente (hurry slowly)<br /> *Id est (that is)<br /> <br /> ----<br /> ===Slackware resources===<br /> *slackware.com<br /> *slackbuilds.org<br /> *kernel.org<br /> *slackbook.org<br /> *slackwiki.org<br /> *sbopkg.org<br /> *linuxquestions.org<br /> *alienBOB&#039;s wiki<br /> *alienBOB&#039;s slackbuilds<br /> * ##slackware<br /> * #slackbuilds<br /> *slackware-annouce@slackware.com<br /> *slackware-security@slackware.com<br /> *slackbuilds-users@slackbuilds.org<br /> *linux-kernel@vger.kernel.org<br /> <br /> <br /> ===Backend/Server Components===<br /> <br /> *[[durchcoderd]]<br /> *[[herrd]]<br /> *[[rissd]]<br /> *[[seherd]]<br /> *[[unterhalterd]]<br /> <br /> ===Frontend/Client Components===<br /> <br /> *[[nackt]]<br /> *[[spieler]]<br /> *[[wunscher]]<br /> <br /> ===Database Design and Synchronization===<br /> <br /> *[[Tables]]<br /> *[[Managed Objects]]<br /> *[[Queues]]<br /> *[[Synchronization]]<br /> *[[Clients]]<br /> <br /> ===Components to Harness===<br /> <br /> *[[libgpod]]<br /> *[[vlc]]<br /> *[[mplayer]]<br /> *[[mpg123]]<br /> *[[mencoder]]<br /> *[[curses]]<br /> *[[ajax]]<br /> *[[firefox]]<br /> *[[wiimote mouse]]<br /> *[[tvshows from online]]<br /> *[http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites Auto deps for makefiles]<br /> *[http://www.fftw.org/doc/Complex-One_002dDimensional-DFTs.html fftw tutorial]<br /> *[http://en.wikipedia.org/wiki/Discrete_Fourier_transform stuff on DFT]<br /> *[http://www.grinninglizard.com/tinyxmldocs/index.html TinyXML]<br /> <br /> ===Other Related Projects===<br /> <br /> *[[bittorrent]]<br /> *[[blogging queue]]<br /> *[[mpr stream capture]]<br /> *[[photo management]]<br /> *[[email grabber]]<br /> *[[tag clouds]]<br /> *[[remote control device]]<br /> *[[dialup server system]]<br /> *[[distributed internal network]]<br /> *[[dvdlookup.org]]<br /> *[[playlist]]<br /> *[[slackpkg plus plus]]<br /> *[[gkrellm replacement]]<br /> *[[book cataloging]]<br /> *[[some avr stuff]]<br /> *[[modjs]]<br /> *[[thoughts on avr event scheduling]]<br /> *[[MIDI and the organ project]]<br /> *[[some sess doc stuff]]<br /> *[[generic document structure objects]]<br /> *[[pennyworth]]<br /> *[[awesome keyboard]]<br /> ----<br /> <br /> ===Stuff to get working on my computers===<br /> *[[xvmc]]<br /> *[[nis]]<br /> *[[proper dhcp]]<br /> *[[special fw on router]]</div>

Admin http://sessrumnir.net/fernseher/index.php?title=MIDI_and_the_organ_project&diff=2165 2011-03-16T22:31:19Z

<p>Admin: </p> <hr /> <div>*[http://sessrumnir.net/organs/trunk/ SVN trunk for organ code]<br /> *[http://www.die-orgelseite.de/pfeifenarten_e.htm Interesting site for pipe shapes and sounds]<br /> <br /> *[[Pipe creation workflow]]<br /> *[[Theoretical Pipe Variations]]<br /> *[[Spectra]]<br /> *[[Other stuff]]<br /> <br /> ====MIDI and the organ====<br /> MIDI standard is out there. Also good is the RTP-MIDI RFC, for putting MIDI data into a stream and whatnot.<br /> <br /> The basics, as I think we will be using them:<br /> <br /> Packet basics (we&#039;ll only be using 3 byte packet forms):<br /> <br /> 1 &lt;3: opcode&gt; &lt;4: channel&gt; 0 &lt;7: arg1&gt; 0 &lt;7: arg2&gt;<br /> <br /> Essentially, a status byte, with the high bit on (0x80-0xFF), and two argument bytes, with the high bit off (0x00-0x7F).<br /> <br /> opcodes of relevance:<br /> *0x0: key off. arg1 is the key number, arg2 is the velocity. We will always use velocity of 0x40.<br /> *0x1: key on. arg1 is the key number, arg2 is the velocity. We will always use the velocity of 0x40.<br /> *0x3: control change. arg1 is the control number (0x01 is modulation wheel, 0x0B is the expression pedal), arg2 is the new control value, from 0x00 - 0x7F (Note: If we need more than 127 steps, add 0x20 to the control number, and thats the control number to use to send the least significant 7-bits of the value. The value sent with the base control number is considered to be the most significant 7-bits of the value. This ensures that if just read the base control number, you set the control to approximately the correct percentage of fully off/fully on.)<br /> <br /> For channels, we will use:<br /> *0x0: Great (Solo) Manual<br /> *0x1: Swell (Accompaniment) Manual<br /> *0x2: Choir (below Great) Manual, if present<br /> *0x3: Solo (above Swell) Manual, if present<br /> *0x4: Echo (above Solo) Manual, if present<br /> *0x5: Third Pedalboard, if present, or the auxilary stop channel, covering additional stops for all manuals and pedals.<br /> *0x6: Second Pedalboard, if present, or the main stop channel, covering all stops for all manuals and pedals.<br /> *0x7: Main Pedalboard<br /> *0x8: Great stops only<br /> *0x9: Swell stops only<br /> *0xA: Choir stops only<br /> *0xB: Solo stops only<br /> *0xC: Echo stops only<br /> *0xD: Third Pedalboard stops only<br /> *0xE: Second Pedalboard stops only<br /> *0xF: Main Pedalboard stops only<br /> <br /> Our initial organ will only use channels 0x0-0x1, 0x6-0x7.<br /> <br /> Each keyboard channel (0x0-0x7) gets its own control set. For our organ, where the modulation wheel and expression pedal control all divisions equally, each control change gets sent for each active channel... or maybe just for great, and the software will figure out that they control all the stuff. Note, we may not hook up the modulation wheel when we begin. It&#039;d be kinda a lot harder to make work right, I think.<br /> <br /> We will be building channel combination boards, that take an enable and a sub-channel address, and read back the contents of the addressed buffer. 4 bits of address gets 16 buffers. At 8 bits per buffer, thats 128 inputs for each channel. That matches with midi&#039;s numbering scheme. Alternatively, if you take the LSB of the true channel, and feed it to the 4th address bit of the channel board, and only decode the top 3 bits of the channel to determine channel board enable, you can duplex your channel boards, since we will only be using under 64 inputs per channel. The AVR firmware will have an MIDI offset value for each channel to add to the number received from the board before sending as part of a MIDI command. For most subchannels, this will be 36. Will probably just use an offset of 0 for the stop channels.<br /> <br /> Using the split channel board design, we only need two channel boards for our organ. The main board will be designed to use the channel boards in split mode, and will never probably use the split-mode stop channels (0x8-0xF), so it will only have 4 plugs for channel boards, 0x0-0x1, 0x2-0x3, 0x4-0x5, and 0x6-0x7. The initial organ will only use the first and last of these plugs, so we don&#039;t even need to populate the board positions for the other channel boards.<br /> <br /> Also, I think we might want to put all the switch pull-up resistors on the manuals themselves, soldered to the key tabs. This will eliminate a lot of crap on the boards, and keep the board design uniform, since the different keys will need different pull-ups. The manuals, with their 5k internal resistance, will need 50k (or so) pull-ups to 5V, and the pedals and stops, with no internal resistance, will need just 10k (or so) pull-ups to 5V. Each manual will get a separate power and ground plug for the pull-ups and grounds, so the connectors for the keys don&#039;t need a pin for ground or power, I don&#039;t think... Though if there is room, I guess we could send it along there, too. Can&#039;t hurt anything, provided the wires support enough current for the crazy case of all the stop pulled or keys pressed or something. Given a max of 64 inputs to a half-channel, and only 61 keys on a full manual, we can use 2x36 pin connectors for the manuals, and 1x36 pin connector for the pedalboards, and 1x36 pin connector for the stop boards. Thats 6 total 36 pin connectors, male and female, solder cup and through-hole.<br /> <br /> Channel board to main board connectors will have an 8-bit data bus, 4-bit address bus, a power, ground, enable, and identify(?) pins (16 total). Should be able to use IDC connectors and ribbon cable here.<br /> <br /> ===Simple algorithm for key change detection===<br /> After reading a byte from the buffers, we xor it with the copy of the byte from last time, then store the new version in the copy location. We then start looking at the lsb of the xor&#039;ed byte. If its a 1, we send a key on if the lsb of the read byte is a 1, and a key off if the lsb of the read byte is a 0. We then shift right and do that again. We do that 8 times, once for each bit in that byte. Then we can move on to the next valid address for that channel, write out the address, read back the buffer value, xor, store, analyze, etc. Note, we can speed this up by checking if the xor byte is identically 0x00, in which case we don&#039;t have to analyze it, it hasn&#039;t changed. This will be the usual case! Only occasionally (in sample time), will things change, and usually only on one bit, and thus one buffer, amongst all the channels and buffers. This should help us keep up to speed.<br /> <br /> Once we are done reading all the channel board buffers, we can check the expression pedals and other variable controls for new values, and possibly send control change events. After all this, we actually send the MIDI bytes as we have determined them to need to be for this time around, and go to sleep until our next sample time.<br /> <br /> Not sure what the latency of the serial to USB conversion is in FTDI, but it could be as bad as a single byte in a single USB message.... Anyway, we want to build a buffer of bytes that need to get send over each sample time, with the RTP-MIDI spec used to make it a stream type thing. This means: packet length, &quot;timestamp&quot;, first MIDI event, relative timestamps (should all be zero), subsequent MIDI events.<br /> <br /> ===Chips to use===<br /> *16x? 74HCT540 for the octal tri-state buffers, inverting (0.54, 20 pin dip)<br /> *1x? 74HCT138 for 1 to 8 decoder (0.40, 16 pin dip)<br /> *1x? 74HCT154 for 1 to 16 decoder (0.80, 24 pin dip)<br /> *1x ATMega164P-20P for AVR controller, 20MHz, (4.82, 40 pin dip)<br /> <br /> <br /> ===Stuff from the old Google Notebook stuff===<br /> ====Pin layout====<br /> *8 data (D7-D0)<br /> *8 address (A7-A0)<br /> *5 inverted address (/A7-/A3)<br /> *1 power (V)<br /> *1 ground (G)<br /> *1 card select (S)<br /> *1 R/W (R)<br /> *1 Presence detect (P)<br /> 1 2 3 4 5 6 7 8 9 10 11 12 13<br /> 1 V S R P G A0-------A2 A3--------------A7<br /> 2 D0---------------Data--------D7 /A3------------/A7<br /> <br /> ====Alternative Input Detection====<br /> Using 40pin AVR, we can use a lot of digital inputs directly to the AVR. We have to use some for normal things. On the slave:<br /> *Vcc<br /> *Gnd<br /> *Reset<br /> *XTAL1<br /> *XTAL2<br /> *UART RX (all tied to CNTR TX)<br /> *UART TX (all tied to MIDI out + CNTR RX)<br /> *RTS<br /> *CTS<br /> Thats 9 pins, so 31 are left for digital inputs for keys/stops (per controller).<br /> <br /> On the master (CNTR):<br /> *Vcc<br /> *Gnd<br /> *Reset<br /> *XTAL1<br /> *XTAL2<br /> *UART1 RX (tied to all Slave TXs)<br /> *UART1 TX (tied to all Slave RXs)<br /> *MOSI<br /> *MISO<br /> *SCK<br /> *UART2 RX (from host)<br /> *UART2 TX (to host)<br /> Thats 12 pins, so 28 are left for RTS/CTS controls for each slave. That means a max of 14 slaves. However, if we use some ADCs on the master for analog controls, we might lose some possible slaves. Or, the analog controls could be fed to a slave controller, or a dedicated controller.<br /> <br /> If we have what you might hope would be a max config:<br /> *5 manuals@61 keys is 2 slaves/manual, or 10 max<br /> *1 pedalboard@30/32 keys is 1 slaves/pedalboard, or 1 max (Note: 32 wouldn&#039;t fit...)<br /> *1 set of stops@60 stops or so is 2 slaves/stop set, or 2 max<br /> That gives us about 13 boards. Maybe the last slave could be used for more stops, or analog controls.</div>

Admin http://sessrumnir.net/fernseher/index.php?title=MIDI_and_the_organ_project&diff=2164 2011-03-16T22:30:45Z

<p>Admin: </p> <hr /> <div>*[http://sessrumnir.net/organs/trunk/ SVN trunk for organ code]<br /> *[http://www.die-orgelseite.de/pfeifenarten_e.htm Interesting site for pipe shapes and sounds]<br /> <br /> *[[Pipe creation workflow]]<br /> *[[Theoretical Pipe Variations]]<br /> *[[Spectra]]<br /> *[[Other stuff]]<br /> <br /> ====MIDI and the organ====<br /> MIDI standard is out there. Also good is the RTP-MIDI RFC, for putting MIDI data into a stream and whatnot.<br /> <br /> The basics, as I think we will be using them:<br /> <br /> Packet basics (we&#039;ll only be using 3 byte packet forms):<br /> <br /> 1 &lt;3: opcode&gt; &lt;4: channel&gt; 0 &lt;7: arg1&gt; 0 &lt;7: arg2&gt;<br /> <br /> Essentially, a status byte, with the high bit on (0x80-0xFF), and two argument bytes, with the high bit off (0x00-0x7F).<br /> <br /> opcodes of relevance:<br /> *0x0: key off. arg1 is the key number, arg2 is the velocity. We will always use velocity of 0x40.<br /> *0x1: key on. arg1 is the key number, arg2 is the velocity. We will always use the velocity of 0x40.<br /> *0x3: control change. arg1 is the control number (0x01 is modulation wheel, 0x0B is the expression pedal), arg2 is the new control value, from 0x00 - 0x7F (Note: If we need more than 127 steps, add 0x20 to the control number, and thats the control number to use to send the least significant 7-bits of the value. The value sent with the base control number is considered to be the most significant 7-bits of the value. This ensures that if just read the base control number, you set the control to approximately the correct percentage of fully off/fully on.)<br /> <br /> For channels, we will use:<br /> *0x0: Great (Solo) Manual<br /> *0x1: Swell (Accompaniment) Manual<br /> *0x2: Choir (below Great) Manual, if present<br /> *0x3: Solo (above Swell) Manual, if present<br /> *0x4: Echo (above Solo) Manual, if present<br /> *0x5: Third Pedalboard, if present, or the auxilary stop channel, covering additional stops for all manuals and pedals.<br /> *0x6: Second Pedalboard, if present, or the main stop channel, covering all stops for all manuals and pedals.<br /> *0x7: Main Pedalboard<br /> *0x8: Great stops only<br /> *0x9: Swell stops only<br /> *0xA: Choir stops only<br /> *0xB: Solo stops only<br /> *0xC: Echo stops only<br /> *0xD: Third Pedalboard stops only<br /> *0xE: Second Pedalboard stops only<br /> *0xF: Main Pedalboard stops only<br /> <br /> Our initial organ will only use channels 0x0-0x1, 0x6-0x7.<br /> <br /> Each keyboard channel (0x0-0x7) gets its own control set. For our organ, where the modulation wheel and expression pedal control all divisions equally, each control change gets sent for each active channel... or maybe just for great, and the software will figure out that they control all the stuff. Note, we may not hook up the modulation wheel when we begin. It&#039;d be kinda a lot harder to make work right, I think.<br /> <br /> We will be building channel combination boards, that take an enable and a sub-channel address, and read back the contents of the addressed buffer. 4 bits of address gets 16 buffers. At 8 bits per buffer, thats 128 inputs for each channel. That matches with midi&#039;s numbering scheme. Alternatively, if you take the LSB of the true channel, and feed it to the 4th address bit of the channel board, and only decode the top 3 bits of the channel to determine channel board enable, you can duplex your channel boards, since we will only be using under 64 inputs per channel. The AVR firmware will have an MIDI offset value for each channel to add to the number received from the board before sending as part of a MIDI command. For most subchannels, this will be 36. Will probably just use an offset of 0 for the stop channels.<br /> <br /> Using the split channel board design, we only need two channel boards for our organ. The main board will be designed to use the channel boards in split mode, and will never probably use the split-mode stop channels (0x8-0xF), so it will only have 4 plugs for channel boards, 0x0-0x1, 0x2-0x3, 0x4-0x5, and 0x6-0x7. The initial organ will only use the first and last of these plugs, so we don&#039;t even need to populate the board positions for the other channel boards.<br /> <br /> Also, I think we might want to put all the switch pull-up resistors on the manuals themselves, soldered to the key tabs. This will eliminate a lot of crap on the boards, and keep the board design uniform, since the different keys will need different pull-ups. The manuals, with their 5k internal resistance, will need 50k (or so) pull-ups to 5V, and the pedals and stops, with no internal resistance, will need just 10k (or so) pull-ups to 5V. Each manual will get a separate power and ground plug for the pull-ups and grounds, so the connectors for the keys don&#039;t need a pin for ground or power, I don&#039;t think... Though if there is room, I guess we could send it along there, too. Can&#039;t hurt anything, provided the wires support enough current for the crazy case of all the stop pulled or keys pressed or something. Given a max of 64 inputs to a half-channel, and only 61 keys on a full manual, we can use 2x36 pin connectors for the manuals, and 1x36 pin connector for the pedalboards, and 1x36 pin connector for the stop boards. Thats 6 total 36 pin connectors, male and female, solder cup and through-hole.<br /> <br /> Channel board to main board connectors will have an 8-bit data bus, 4-bit address bus, a power, ground, enable, and identify(?) pins (16 total). Should be able to use IDC connectors and ribbon cable here.<br /> <br /> ===Simple algorithm for key change detection===<br /> After reading a byte from the buffers, we xor it with the copy of the byte from last time, then store the new version in the copy location. We then start looking at the lsb of the xor&#039;ed byte. If its a 1, we send a key on if the lsb of the read byte is a 1, and a key off if the lsb of the read byte is a 0. We then shift right and do that again. We do that 8 times, once for each bit in that byte. Then we can move on to the next valid address for that channel, write out the address, read back the buffer value, xor, store, analyze, etc. Note, we can speed this up by checking if the xor byte is identically 0x00, in which case we don&#039;t have to analyze it, it hasn&#039;t changed. This will be the usual case! Only occasionally (in sample time), will things change, and usually only on one bit, and thus one buffer, amongst all the channels and buffers. This should help us keep up to speed.<br /> <br /> Once we are done reading all the channel board buffers, we can check the expression pedals and other variable controls for new values, and possibly send control change events. After all this, we actually send the MIDI bytes as we have determined them to need to be for this time around, and go to sleep until our next sample time.<br /> <br /> Not sure what the latency of the serial to USB conversion is in FTDI, but it could be as bad as a single byte in a single USB message.... Anyway, we want to build a buffer of bytes that need to get send over each sample time, with the RTP-MIDI spec used to make it a stream type thing. This means: packet length, &quot;timestamp&quot;, first MIDI event, relative timestamps (should all be zero), subsequent MIDI events.<br /> <br /> ===Chips to use===<br /> *16x? 74HCT540 for the octal tri-state buffers, inverting (0.54, 20 pin dip)<br /> *1x? 74HCT138 for 1 to 8 decoder (0.40, 16 pin dip)<br /> *1x? 74HCT154 for 1 to 16 decoder (0.80, 24 pin dip)<br /> *1x ATMega164P-20P for AVR controller, 20MHz, (4.82, 40 pin dip)<br /> <br /> <br /> ===Stuff from the old Google Notebook stuff===<br /> _Pin layout_<br /> *8 data (D7-D0)<br /> *8 address (A7-A0)<br /> *5 inverted address (/A7-/A3)<br /> *1 power (V)<br /> *1 ground (G)<br /> *1 card select (S)<br /> *1 R/W (R)<br /> *1 Presence detect (P)<br /> 1 2 3 4 5 6 7 8 9 10 11 12 13<br /> 1 V S R P G A0-------A2 A3--------------A7<br /> 2 D0---------------Data--------D7 /A3------------/A7<br /> <br /> _Alternative Input Detection_<br /> Using 40pin AVR, we can use a lot of digital inputs directly to the AVR. We have to use some for normal things. On the slave:<br /> *Vcc<br /> *Gnd<br /> *Reset<br /> *XTAL1<br /> *XTAL2<br /> *UART RX (all tied to CNTR TX)<br /> *UART TX (all tied to MIDI out + CNTR RX)<br /> *RTS<br /> *CTS<br /> Thats 9 pins, so 31 are left for digital inputs for keys/stops (per controller).<br /> <br /> On the master (CNTR):<br /> *Vcc<br /> *Gnd<br /> *Reset<br /> *XTAL1<br /> *XTAL2<br /> *UART1 RX (tied to all Slave TXs)<br /> *UART1 TX (tied to all Slave RXs)<br /> *MOSI<br /> *MISO<br /> *SCK<br /> *UART2 RX (from host)<br /> *UART2 TX (to host)<br /> Thats 12 pins, so 28 are left for RTS/CTS controls for each slave. That means a max of 14 slaves. However, if we use some ADCs on the master for analog controls, we might lose some possible slaves. Or, the analog controls could be fed to a slave controller, or a dedicated controller.<br /> <br /> If we have what you might hope would be a max config:<br /> *5 manuals@61 keys is 2 slaves/manual, or 10 max<br /> *1 pedalboard@30/32 keys is 1 slaves/pedalboard, or 1 max (Note: 32 wouldn&#039;t fit...)<br /> *1 set of stops@60 stops or so is 2 slaves/stop set, or 2 max<br /> That gives us about 13 boards. Maybe the last slave could be used for more stops, or analog controls.</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Pennyworth&diff=2163 2010-05-24T23:33:01Z

<p>Admin: Created page with &#039;bookmarklet grabs the asin from the page, and the url, and maybe the page title (as description). Then presents the user with that info, and the ability to override the asin, de…&#039;</p> <hr /> <div>bookmarklet grabs the asin from the page, and the url, and maybe the page title (as description). Then presents the user with that info, and the ability to override the asin, description, default quantity of 1, importance, and maybe a price setting, if the user desires to not look it up all the time.<br /> <br /> That info, with the session id cookie (if present) and originating ip is sent to the server, which adds it to the item table based on the session id&#039;s userid (or does a login), the date, and a state indicating it should be involved in calculations.<br /> <br /> A daemon should run to fetch data from amazon, including price, availability, etc., and put that into a table to keep track of each item&#039;s price (including already purchased ones?)<br /> <br /> Another daemon runs to distribute available money (as calculated) and assign it to each item, based on importance, price, availability, quantity, and date added. If something can be purchased, it may send an email to the user with a link to the webpage or shopping cart directly.<br /> <br /> The webpage allows logging in and out (which makes/destroys a session cookie), creating a user. Adjust amount of money currently available, adjust automatic money increases. User settings (purchase rate, algorithm, etc)<br /> <br /> Also provides a way to see all the items, and from there, directly add new ones, delete some, change whether an item participates in calculations, directly buy the item, adjust asin, description, price, quantity, importance. Price history.<br /> <br /> Lets you see what items you can buy right now and adjust that cart to defer purchasing something, or purchase something outside of amazon, etc.<br /> <br /> Lets you mark that you already bought something elsewhere, and how that should adjust the available cash.<br /> <br /> You can also see when the current rate of new money, algorithm, etc, would want you to purchase a given item.<br /> <br /> You can see old items, and old purchases.</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Fernseher&diff=2162 2010-05-24T23:24:44Z

<p>Admin: /* Other Related Projects */</p> <hr /> <div>Fernseher is an all encompassing set of scripts to solve all the world&#039;s problems, determine whether P really does equal NP, make me lots of money, and make a fool of myself, all at once. I imagine it will be useful to no one, do exactly what no one wants it to do, and be accused of murder and money laundering multiple times. If it does what you want it to do, reconsider, because you are probably wrong. It won&#039;t even do what I want it to do, and I wrote the damn thing.<br /> <br /> In summation, your probably don&#039;t really want this set of crap on your box, and if you put it on your box, it is likely that your computer will implode, and almost certain that all your base will belong to me.<br /> <br /> That said, I am using this wiki to keep track of ideas I have for the various components involved, what they do, what they should do, how to use them, how to improve them, and what will happen if you don&#039;t use them with everything else. I am also hoping to do some rudimentary interface design here for the various front ends, as well as backend database design so I know how its all supposed to go together. I may also put any information I have on the various utilities I plan on using to interface with the tuner cards, as well as interfaces to play music and video, adjust channels, volume, use bittorrent, etc. <br /> <br /> *Festina lente (hurry slowly)<br /> *Id est (that is)<br /> <br /> ----<br /> ===Slackware resources===<br /> *slackware.com<br /> *slackbuilds.org<br /> *kernel.org<br /> *slackbook.org<br /> *slackwiki.org<br /> *sbopkg.org<br /> *linuxquestions.org<br /> *alienBOB&#039;s wiki<br /> *alienBOB&#039;s slackbuilds<br /> * ##slackware<br /> * #slackbuilds<br /> *slackware-annouce@slackware.com<br /> *slackware-security@slackware.com<br /> *slackbuilds-users@slackbuilds.org<br /> *linux-kernel@vger.kernel.org<br /> <br /> <br /> ===Backend/Server Components===<br /> <br /> *[[durchcoderd]]<br /> *[[herrd]]<br /> *[[rissd]]<br /> *[[seherd]]<br /> *[[unterhalterd]]<br /> <br /> ===Frontend/Client Components===<br /> <br /> *[[nackt]]<br /> *[[spieler]]<br /> *[[wunscher]]<br /> <br /> ===Database Design and Synchronization===<br /> <br /> *[[Tables]]<br /> *[[Managed Objects]]<br /> *[[Queues]]<br /> *[[Synchronization]]<br /> *[[Clients]]<br /> <br /> ===Components to Harness===<br /> <br /> *[[libgpod]]<br /> *[[vlc]]<br /> *[[mplayer]]<br /> *[[mpg123]]<br /> *[[mencoder]]<br /> *[[curses]]<br /> *[[ajax]]<br /> *[[firefox]]<br /> *[[wiimote mouse]]<br /> *[[tvshows from online]]<br /> *[http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites Auto deps for makefiles]<br /> *[http://www.fftw.org/doc/Complex-One_002dDimensional-DFTs.html fftw tutorial]<br /> *[http://en.wikipedia.org/wiki/Discrete_Fourier_transform stuff on DFT]<br /> *[http://www.grinninglizard.com/tinyxmldocs/index.html TinyXML]<br /> <br /> ===Other Related Projects===<br /> <br /> *[[bittorrent]]<br /> *[[blogging queue]]<br /> *[[mpr stream capture]]<br /> *[[photo management]]<br /> *[[email grabber]]<br /> *[[tag clouds]]<br /> *[[remote control device]]<br /> *[[dialup server system]]<br /> *[[distributed internal network]]<br /> *[[dvdlookup.org]]<br /> *[[playlist]]<br /> *[[slackpkg plus plus]]<br /> *[[gkrellm replacement]]<br /> *[[book cataloging]]<br /> *[[some avr stuff]]<br /> *[[modjs]]<br /> *[[thoughts on avr event scheduling]]<br /> *[[MIDI and the organ project]]<br /> *[[some sess doc stuff]]<br /> *[[generic document structure objects]]<br /> *[[pennyworth]]<br /> ----<br /> <br /> ===Stuff to get working on my computers===<br /> *[[xvmc]]<br /> *[[nis]]<br /> *[[proper dhcp]]<br /> *[[special fw on router]]</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Generic_document_structure_objects&diff=2161 2010-05-19T21:15:12Z

<p>Admin: </p> <hr /> <div>Two parts:<br /> *data structures representing the document structure<br /> *text formatting<br /> <br /> It&#039;s important to keep the distinction between the two. Representations for the first are independant of representations for the second.<br /> <br /> I&#039;d like the first (data structures) to be something that can easily and directly translate between languages, container formats, databases, etc.<br /> The second (formating) should primarily be unified across all data structure types and formats, but there might be alternative representations for XHTML.<br /> <br /> We can address the formatting first:<br /> <br /> *bold text<br /> &lt;b&gt; tags for XHTML &lt;/b&gt;<br /> <br /> *italic text<br /> &lt;i&gt; tags for XHTML &lt;/i&gt;<br /> <br /> *underline text<br /> &lt;u&gt; tags for XHTML &lt;/u&gt;<br /> <br /> *strikethrough text<br /> &lt;s&gt; tags for XHTML &lt;/s&gt;<br /> <br /> *monospaced text<br /> &lt;m&gt; tags for XHMTL? &lt;/m&gt;<br /> <br /> *enumerated lists<br /> &lt;ol&gt; tags in XHTML &lt;/ol&gt;<br /> <br /> *itemized lists<br /> &lt;ul&gt; tags in XHTML &lt;/ul&gt;<br /> <br /> *description lists<br /> &lt;dl&gt; tags in XHTML &lt;/dl&gt;<br /> <br /> *tex inline math<br /> $ &quot;tag&quot; in TeX<br /> <br /> *references (both internal and external)<br /> <br /> Ensure that we allow unicode characters and maybe XHTML character entities?<br /> <br /> <br /> <br /> The data structure should be easy to put into YAML, JSON, XML. It should be directly representable by nested hashes and arrays in javascript and perl.<br /> <br /> Object types:<br /> *Document: contains information about the entire document and points to contained Sections (as pre-matter, main body, and appendices).<br /> *Section: Contains content in the form of Paragraphs, Figures, Tables, Code Fragments, Equations.<br /> *Paragraph: Contains text content.<br /> *Figure: Contains image content.<br /> *Table: Contains tabular format (data).<br /> *Code: Contains code listings.<br /> *Equation: Contains non-inline TeX equations (or mathml I suppose).<br /> <br /> For each item, it could contain verbatim text, formatted text, data, image blobs, URIs to find the information, etc., as appropriate for the type.<br /> <br /> *Most of these objects have id fields, specifying a way to refer to the given section, figure, etc.<br /> *Most have title fields, which would be used to identify the section, etc, in tables of contents, figures, bibliographies, etc., as well as titles in the section text itself.<br /> *A url field may be present which would be used to get the data for the section.<br /> *Alternatively, a blob field could be present, where the section&#039;s data would be directly included in the data structure.<br /> *If either the url or blob field is present, a type field would specify how to interpret the data at the URL, or the data in the blob. The default type depends on the type of object and the fields that the data is in.<br /> *Some objects may have caption fields to show by the figure/table/etc.<br /> *Some objects may contain other fields to represent the data in a different way.</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Generic_document_structure_objects&diff=2160 2010-05-19T21:14:09Z

<p>Admin: </p> <hr /> <div>Two parts:<br /> *data structures representing the document structure<br /> *text formatting<br /> <br /> It&#039;s important to keep the distinction between the two. Representations for the first are independant of representations for the second.<br /> <br /> I&#039;d like the first (data structures) to be something that can easily and directly translate between languages, container formats, databases, etc.<br /> The second (formating) should primarily be unified across all data structure types and formats, but there might be alternative representations for XHTML.<br /> <br /> We can address the formatting first:<br /> <br /> *bold text<br /> &lt;b&gt; tags for XHTML &lt;/b&gt;<br /> <br /> *italic text<br /> &lt;i&gt; tags for XHTML &lt;/i&gt;<br /> <br /> *underline text<br /> &lt;u&gt; tags for XHTML &lt;/u&gt;<br /> <br /> *strikethrough text<br /> &lt;s&gt; tags for XHTML &lt;/s&gt;<br /> <br /> *monospaced text<br /> &lt;m&gt; tags for XHMTL? &lt;/m&gt;<br /> <br /> *enumerated lists<br /> &lt;ol&gt; tags in XHTML &lt;/ol&gt;<br /> <br /> *itemized lists<br /> &lt;ul&gt; tags in XHTML &lt;/ul&gt;<br /> <br /> *description lists<br /> &lt;dl&gt; tags in XHTML &lt;/dl&gt;<br /> <br /> *tex inline math<br /> $ &quot;tag&quot; in TeX<br /> <br /> *references (both internal and external)<br /> <br /> Ensure that we allow unicode characters and maybe XHTML character entities?<br /> <br /> <br /> <br /> The data structure should be easy to put into YAML, JSON, XML. It should be directly representable by nested hashes and arrays in javascript and perl.<br /> <br /> Object types:<br /> -------------<br /> Document: contains information about the entire document and points to contained Sections (as pre-matter, main body, and appendices).<br /> Section: Contains content in the form of Paragraphs, Figures, Tables, Code Fragments, Equations.<br /> Paragraph: Contains text content.<br /> Figure: Contains image content.<br /> Table: Contains tabular format (data).<br /> Code: Contains code listings.<br /> Equation: Contains non-inline TeX equations (or mathml I suppose).<br /> <br /> For each item, it could contain verbatim text, formatted text, data, image blobs, URIs to find the information, etc., as appropriate for the type.<br /> <br /> Most of these objects have id fields, specifying a way to refer to the given section, figure, etc.<br /> Most have title fields, which would be used to identify the section, etc, in tables of contents, figures, bibliographies, etc., as well as titles in the section text itself.<br /> A url field may be present which would be used to get the data for the section.<br /> Alternatively, a blob field could be present, where the section&#039;s data would be directly included in the data structure.<br /> If either the url or blob field is present, a type field would specify how to interpret the data at the URL, or the data in the blob. The default type depends on the type of object and the fields that the data is in.<br /> Some objects may have caption fields to show by the figure/table/etc.<br /> Some objects may contain other fields to represent the data in a different way.</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Generic_document_structure_objects&diff=2159 2010-05-19T21:13:07Z

<p>Admin: </p> <hr /> <div>Two parts:<br /> *data structures representing the document structure<br /> *text formatting<br /> <br /> It&#039;s important to keep the distinction between the two. Representations for the first are independant of representations for the second.<br /> <br /> I&#039;d like the first (data structures) to be something that can easily and directly translate between languages, container formats, databases, etc.<br /> The second (formating) should primarily be unified across all data structure types and formats, but there might be alternative representations for XHTML.<br /> <br /> We can address the formatting first:<br /> <br /> *bold text<br /> &lt;b&gt; tags for XHTML &lt;/b&gt;<br /> <br /> *italic text<br /> &lt;i&gt; tags for XHTML &lt;/i&gt;<br /> <br /> *underline text<br /> &lt;u&gt; tags for XHTML &lt;/u&gt;<br /> <br /> *strikethrough text<br /> &lt;s&gt; tags for XHTML? &lt;/s&gt;<br /> <br /> *monospaced text<br /> &lt;m&gt; tags for XHMTL? &lt;/m&gt;<br /> <br /> *enumerated lists<br /> &lt;ol&gt; tags in XHTML &lt;/ol&gt;<br /> <br /> *itemized lists<br /> &lt;ul&gt; tags in XHTML &lt;/ul&gt;<br /> <br /> *description lists<br /> &lt;dd&gt; tags in XHTML &lt;/dd&gt;<br /> <br /> *tex inline math<br /> $ &quot;tag&quot; in TeX<br /> <br /> *references (both internal and external)<br /> <br /> Ensure that we allow unicode characters and maybe XHTML character entities?<br /> <br /> <br /> <br /> The data structure should be easy to put into YAML, JSON, XML. It should be directly representable by nested hashes and arrays in javascript and perl.<br /> <br /> Object types:<br /> -------------<br /> Document: contains information about the entire document and points to contained Sections (as pre-matter, main body, and appendices).<br /> Section: Contains content in the form of Paragraphs, Figures, Tables, Code Fragments, Equations.<br /> Paragraph: Contains text content.<br /> Figure: Contains image content.<br /> Table: Contains tabular format (data).<br /> Code: Contains code listings.<br /> Equation: Contains non-inline TeX equations (or mathml I suppose).<br /> <br /> For each item, it could contain verbatim text, formatted text, data, image blobs, URIs to find the information, etc., as appropriate for the type.<br /> <br /> Most of these objects have id fields, specifying a way to refer to the given section, figure, etc.<br /> Most have title fields, which would be used to identify the section, etc, in tables of contents, figures, bibliographies, etc., as well as titles in the section text itself.<br /> A url field may be present which would be used to get the data for the section.<br /> Alternatively, a blob field could be present, where the section&#039;s data would be directly included in the data structure.<br /> If either the url or blob field is present, a type field would specify how to interpret the data at the URL, or the data in the blob. The default type depends on the type of object and the fields that the data is in.<br /> Some objects may have caption fields to show by the figure/table/etc.<br /> Some objects may contain other fields to represent the data in a different way.</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Generic_document_structure_objects&diff=2158 2010-05-19T21:12:09Z

<p>Admin: Created page with &#039;Two parts: *data structures representing the document structure *text formatting It&#039;s important to keep the distinction between the two. Representations for the first are indep…&#039;</p> <hr /> <div>Two parts:<br /> *data structures representing the document structure<br /> *text formatting<br /> <br /> It&#039;s important to keep the distinction between the two. Representations for the first are independant of representations for the second.<br /> <br /> I&#039;d like the first (data structures) to be something that can easily and directly translate between languages, container formats, databases, etc.<br /> The second (formating) should primarily be unified across all data structure types and formats, but there might be alternative representations for XHTML.<br /> <br /> We can address the formatting first:<br /> <br /> *bold text<br /> &lt;b&gt; tags for XHTML<br /> <br /> *italic text<br /> &lt;i&gt; tags for XHTML<br /> <br /> *underline text<br /> &lt;u&gt; tags for XHTML<br /> <br /> *strikethrough text<br /> &lt;s&gt; tags for XHTML?<br /> <br /> *monospaced text<br /> &lt;m&gt; tags for XHMTL?<br /> <br /> *enumerated lists<br /> &lt;ol&gt; tags in XHTML<br /> <br /> *itemized lists<br /> &lt;ul&gt; tags in XHTML<br /> <br /> *description lists<br /> &lt;dd&gt; tags in XHTML<br /> <br /> *tex inline math<br /> $ &quot;tag&quot; in TeX<br /> <br /> *references (both internal and external)<br /> <br /> Ensure that we allow unicode characters and maybe XHTML character entities?<br /> <br /> <br /> <br /> The data structure should be easy to put into YAML, JSON, XML. It should be directly representable by nested hashes and arrays in javascript and perl.<br /> <br /> Object types:<br /> -------------<br /> Document: contains information about the entire document and points to contained Sections (as pre-matter, main body, and appendices).<br /> Section: Contains content in the form of Paragraphs, Figures, Tables, Code Fragments, Equations.<br /> Paragraph: Contains text content.<br /> Figure: Contains image content.<br /> Table: Contains tabular format (data).<br /> Code: Contains code listings.<br /> Equation: Contains non-inline TeX equations (or mathml I suppose).<br /> <br /> For each item, it could contain verbatim text, formatted text, data, image blobs, URIs to find the information, etc., as appropriate for the type.<br /> <br /> Most of these objects have id fields, specifying a way to refer to the given section, figure, etc.<br /> Most have title fields, which would be used to identify the section, etc, in tables of contents, figures, bibliographies, etc., as well as titles in the section text itself.<br /> A url field may be present which would be used to get the data for the section.<br /> Alternatively, a blob field could be present, where the section&#039;s data would be directly included in the data structure.<br /> If either the url or blob field is present, a type field would specify how to interpret the data at the URL, or the data in the blob. The default type depends on the type of object and the fields that the data is in.<br /> Some objects may have caption fields to show by the figure/table/etc.<br /> Some objects may contain other fields to represent the data in a different way.</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Fernseher&diff=2157 2010-05-19T21:09:59Z

<p>Admin: </p> <hr /> <div>Fernseher is an all encompassing set of scripts to solve all the world&#039;s problems, determine whether P really does equal NP, make me lots of money, and make a fool of myself, all at once. I imagine it will be useful to no one, do exactly what no one wants it to do, and be accused of murder and money laundering multiple times. If it does what you want it to do, reconsider, because you are probably wrong. It won&#039;t even do what I want it to do, and I wrote the damn thing.<br /> <br /> In summation, your probably don&#039;t really want this set of crap on your box, and if you put it on your box, it is likely that your computer will implode, and almost certain that all your base will belong to me.<br /> <br /> That said, I am using this wiki to keep track of ideas I have for the various components involved, what they do, what they should do, how to use them, how to improve them, and what will happen if you don&#039;t use them with everything else. I am also hoping to do some rudimentary interface design here for the various front ends, as well as backend database design so I know how its all supposed to go together. I may also put any information I have on the various utilities I plan on using to interface with the tuner cards, as well as interfaces to play music and video, adjust channels, volume, use bittorrent, etc. <br /> <br /> *Festina lente (hurry slowly)<br /> *Id est (that is)<br /> <br /> ----<br /> ===Slackware resources===<br /> *slackware.com<br /> *slackbuilds.org<br /> *kernel.org<br /> *slackbook.org<br /> *slackwiki.org<br /> *sbopkg.org<br /> *linuxquestions.org<br /> *alienBOB&#039;s wiki<br /> *alienBOB&#039;s slackbuilds<br /> * ##slackware<br /> * #slackbuilds<br /> *slackware-annouce@slackware.com<br /> *slackware-security@slackware.com<br /> *slackbuilds-users@slackbuilds.org<br /> *linux-kernel@vger.kernel.org<br /> <br /> <br /> ===Backend/Server Components===<br /> <br /> *[[durchcoderd]]<br /> *[[herrd]]<br /> *[[rissd]]<br /> *[[seherd]]<br /> *[[unterhalterd]]<br /> <br /> ===Frontend/Client Components===<br /> <br /> *[[nackt]]<br /> *[[spieler]]<br /> *[[wunscher]]<br /> <br /> ===Database Design and Synchronization===<br /> <br /> *[[Tables]]<br /> *[[Managed Objects]]<br /> *[[Queues]]<br /> *[[Synchronization]]<br /> *[[Clients]]<br /> <br /> ===Components to Harness===<br /> <br /> *[[libgpod]]<br /> *[[vlc]]<br /> *[[mplayer]]<br /> *[[mpg123]]<br /> *[[mencoder]]<br /> *[[curses]]<br /> *[[ajax]]<br /> *[[firefox]]<br /> *[[wiimote mouse]]<br /> *[[tvshows from online]]<br /> *[http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites Auto deps for makefiles]<br /> *[http://www.fftw.org/doc/Complex-One_002dDimensional-DFTs.html fftw tutorial]<br /> *[http://en.wikipedia.org/wiki/Discrete_Fourier_transform stuff on DFT]<br /> *[http://www.grinninglizard.com/tinyxmldocs/index.html TinyXML]<br /> <br /> ===Other Related Projects===<br /> <br /> *[[bittorrent]]<br /> *[[blogging queue]]<br /> *[[mpr stream capture]]<br /> *[[photo management]]<br /> *[[email grabber]]<br /> *[[tag clouds]]<br /> *[[remote control device]]<br /> *[[dialup server system]]<br /> *[[distributed internal network]]<br /> *[[dvdlookup.org]]<br /> *[[playlist]]<br /> *[[slackpkg plus plus]]<br /> *[[gkrellm replacement]]<br /> *[[book cataloging]]<br /> *[[some avr stuff]]<br /> *[[modjs]]<br /> *[[thoughts on avr event scheduling]]<br /> *[[MIDI and the organ project]]<br /> *[[some sess doc stuff]]<br /> *[[generic document structure objects]]<br /> ----<br /> <br /> ===Stuff to get working on my computers===<br /> *[[xvmc]]<br /> *[[nis]]<br /> *[[proper dhcp]]<br /> *[[special fw on router]]</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Some_sess_doc_stuff&diff=2156 2009-11-11T19:43:57Z

<p>Admin: </p> <hr /> <div>For all of these, the search order for the database URL is: ~/.sessdoc[REPO] &#039;&#039;etc-root&#039;&#039;/etc/sessdoc.conf http://www.sessrumnir.net:80/doc<br /> For load, default is to print the response body, but not the headers or error messages. For store, default is to print nothing.<br /> <br /> *Load<br /> <br /> sessdocget &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] [--noheaders] [--headers] [--nobody] [--body] [--verbose] &gt; &#039;&#039;entity&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> *Store (For all stores, Content-title, From, and Content-type are required. Content-type comes from the branched document for branches. If From is not specified, its gotten from ~/.sessdoc[AUTHOR] or $USER. For put, these things can be specified on the command line or in a simple headers section before the first newline. If any of them are on the command line, it&#039;s assumed that there is no simple headers section and the body starts right away.)<br /> <br /> sessdocput &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] [--type=&#039;&#039;content-type&#039;&#039;] [--title=&#039;&#039;content-title&#039;&#039;] [--author=&#039;&#039;author&#039;&#039;] [--noheaders] [--headers] [--nobody] [--body] [--verbose] &lt; &#039;&#039;entity&#039;&#039; &gt; &#039;&#039;entity&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> sessdocbranch &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &#039;&#039;new-id&#039;&#039; [--title=&#039;&#039;content-title&#039;&#039;] [--author=&#039;&#039;author&#039;&#039;] [--noheaders] [--headers] [--body] [--nobody] [--verbose] &gt; &#039;&#039;entity&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> *Return codes<br /> **64 EX_USAGE Args not understood or missing required args<br /> **69 EX_UNAVAILABLE 500 Can&#039;t connect to repository host/port<br /> **78 EX_CONFIG Problem reading config files? (might not need this one... just move on)<br /> **1 EXIT_FAILURE Internal error that isn&#039;t normal<br /> **65 EX_DATAERR 400 Bad request<br /> **77 EX_NOPERM 409 Not allowed<br /> **79 EX_NOTFOUND 404 No such document/revision<br /> **0 EXIT_SUCCESS 200/201 Success</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Some_sess_doc_stuff&diff=2155 2009-11-11T15:28:06Z

<p>Admin: </p> <hr /> <div>For all of these, the search order for the database URL is: ~/.sessdoc[REPO] &#039;&#039;etc-root&#039;&#039;/etc/sessdoc.conf http://www.sessrumnir.net:80/doc<br /> <br /> *Load<br /> <br /> sessdocget &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &gt; &#039;&#039;entity&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> sessdocget &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] --nohead &gt; &#039;&#039;body&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> sessdochead &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &gt; &#039;&#039;head&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> *Store<br /> <br /> sessdocput &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &lt; &#039;&#039;entity&#039;&#039; ::=&#039;&#039;httprc&#039;&#039; (* headers required: Content-type, Content-title, potentially From: (if From not specified, ~/.sessdoc[AUTHOR] or $USER is used))<br /> <br /> sessdocput &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] --type=&#039;&#039;content-type&#039;&#039; --title=&#039;&#039;content-title&#039;&#039; [--author=&#039;&#039;author&#039;&#039;] &lt; &#039;&#039;body&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> sessdocbranch &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &#039;&#039;new-id&#039;&#039; &lt; &#039;&#039;head&#039;&#039; ::=&#039;&#039;httprc&#039;&#039; (* headers required: Content-title, potentially From: (if From not specified, ~/.sessdoc[AUTHOR] or $USER is used))<br /> <br /> sessdocbranch &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &#039;&#039;new-id&#039;&#039; --title=&#039;&#039;content-title&#039;&#039; [--author=&#039;&#039;author&#039;&#039;] ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> *Return codes<br /> **64 EX_USAGE Args not understood or missing required args<br /> **69 EX_UNAVAILABLE Can&#039;t connect to repository host/port<br /> **78 EX_CONFIG Problem reading config files? (might not need this one... just move on)<br /> **1 EXIT_FAILURE Internal error that isn&#039;t normal<br /> **65 EX_DATAERR 400 Bad request<br /> **77 EX_NOPERM 409 Not allowed<br /> **79 EX_NOTFOUND 404 No such document/revision<br /> **0 EXIT_SUCCESS 200/201 Success</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Some_sess_doc_stuff&diff=2154 2009-11-05T22:30:46Z

<p>Admin: </p> <hr /> <div>For all of these, the search order for the database URL is: ~/.sessdoc[REPO] &#039;&#039;etc-root&#039;&#039;/etc/sessdoc.conf http://www.sessrumnir.net/doc<br /> <br /> *Load<br /> <br /> sessdocget &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &gt; &#039;&#039;entity&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> sessdocget &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] --nohead &gt; &#039;&#039;body&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> sessdochead &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &gt; &#039;&#039;head&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> *Store<br /> <br /> sessdocput &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &lt; &#039;&#039;entity&#039;&#039; ::=&#039;&#039;httprc&#039;&#039; (* headers required: Content-type, Content-title, potentially From: (if From not specified, ~/.sessdoc[AUTHOR] or $USER is used))<br /> <br /> sessdocput &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] --type=&#039;&#039;content-type&#039;&#039; --title=&#039;&#039;content-title&#039;&#039; [--author=&#039;&#039;author&#039;&#039;] &lt; &#039;&#039;body&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> sessdocbranch &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &#039;&#039;new-id&#039;&#039; &lt; &#039;&#039;head&#039;&#039; ::=&#039;&#039;httprc&#039;&#039; (* headers required: Content-title, potentially From: (if From not specified, ~/.sessdoc[AUTHOR] or $USER is used))<br /> <br /> sessdocbranch &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &#039;&#039;new-id&#039;&#039; --title=&#039;&#039;content-title&#039;&#039; [--author=&#039;&#039;author&#039;&#039;] ::=&#039;&#039;httprc&#039;&#039;</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Some_sess_doc_stuff&diff=2153 2009-11-05T22:29:53Z

<p>Admin: </p> <hr /> <div>For all of these, the search order for the database URL is: ~/.sessdoc[REPO] &#039;&#039;etc-root&#039;&#039;/etc/sessdoc.conf http://www.sessrumnir.net/doc<br /> <br /> *Load<br /> <br /> sessdocget &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &gt; &#039;&#039;entity&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> sessdocget &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] --nohead &gt; &#039;&#039;body&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> sessdochead &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &gt; &#039;&#039;head&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> *Store<br /> <br /> sessdocput &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &lt; &#039;&#039;entity&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> ** headers required: Content-type, Content-title, potentially From: (if From not specified, ~/.sessdoc[AUTHOR] or $USER is used).<br /> <br /> sessdocput &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] --type=&#039;&#039;content-type&#039;&#039; --title=&#039;&#039;content-title&#039;&#039; [--author=&#039;&#039;author&#039;&#039;] &lt; &#039;&#039;body&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> sessdocbranch &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &#039;&#039;new-id&#039;&#039; &lt; &#039;&#039;head&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> ** headers required: Content-title, potentially From: (if From not specified, ~/.sessdoc[AUTHOR] or $USER is used).<br /> <br /> sessdocbranch &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &#039;&#039;new-id&#039;&#039; --title=&#039;&#039;content-title&#039;&#039; [--author=&#039;&#039;author&#039;&#039;] ::=&#039;&#039;httprc&#039;&#039;</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Some_sess_doc_stuff&diff=2152 2009-11-05T22:18:25Z

<p>Admin: </p> <hr /> <div>*Load<br /> <br /> sessdocget &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &gt; &#039;&#039;entity&#039;&#039; &quot;&quot;=&#039;&#039;httprc&#039;&#039;<br /> <br /> sessdocget &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] --nohead &gt; &#039;&#039;body&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> sessdochead &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &lt; &#039;&#039;head&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> *Store (author, if not specified, will be ~/.sessdoc[AUTHOR], or userid on localhost)<br /> <br /> sessdocput &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &lt; &#039;&#039;entity&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> sessdocput &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] --type=&#039;&#039;content-type&#039;&#039; --title=&#039;&#039;content-title&#039;&#039; [--author=&#039;&#039;author&#039;&#039;] &lt; &#039;&#039;body&#039;&#039; ::=&#039;&#039;httprc&#039;&#039;<br /> <br /> sessdocbranch &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &#039;&#039;new-id&#039;&#039; [--author=&#039;&#039;author&#039;&#039;] ::=&#039;&#039;httprc&#039;&#039;</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Some_sess_doc_stuff&diff=2151 2009-11-05T22:12:44Z

<p>Admin: Created page with &#039;*sessdocget sessdocget &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &gt; &#039;&#039;entity&#039;&#039; =&#039;&#039;http rc&#039;&#039;&#039;</p> <hr /> <div>*sessdocget<br /> <br /> sessdocget &#039;&#039;id&#039;&#039;[/&#039;&#039;rev&#039;&#039;] &gt; &#039;&#039;entity&#039;&#039; =&#039;&#039;http rc&#039;&#039;</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Fernseher&diff=2150 2009-11-05T22:10:37Z

<p>Admin: </p> <hr /> <div>Fernseher is an all encompassing set of scripts to solve all the world&#039;s problems, determine whether P really does equal NP, make me lots of money, and make a fool of myself, all at once. I imagine it will be useful to no one, do exactly what no one wants it to do, and be accused of murder and money laundering multiple times. If it does what you want it to do, reconsider, because you are probably wrong. It won&#039;t even do what I want it to do, and I wrote the damn thing.<br /> <br /> In summation, your probably don&#039;t really want this set of crap on your box, and if you put it on your box, it is likely that your computer will implode, and almost certain that all your base will belong to me.<br /> <br /> That said, I am using this wiki to keep track of ideas I have for the various components involved, what they do, what they should do, how to use them, how to improve them, and what will happen if you don&#039;t use them with everything else. I am also hoping to do some rudimentary interface design here for the various front ends, as well as backend database design so I know how its all supposed to go together. I may also put any information I have on the various utilities I plan on using to interface with the tuner cards, as well as interfaces to play music and video, adjust channels, volume, use bittorrent, etc. <br /> <br /> *Festina lente (hurry slowly)<br /> *Id est (that is)<br /> <br /> ----<br /> ===Slackware resources===<br /> *slackware.com<br /> *slackbuilds.org<br /> *kernel.org<br /> *slackbook.org<br /> *slackwiki.org<br /> *sbopkg.org<br /> *linuxquestions.org<br /> *alienBOB&#039;s wiki<br /> *alienBOB&#039;s slackbuilds<br /> * ##slackware<br /> * #slackbuilds<br /> *slackware-annouce@slackware.com<br /> *slackware-security@slackware.com<br /> *slackbuilds-users@slackbuilds.org<br /> *linux-kernel@vger.kernel.org<br /> <br /> <br /> ===Backend/Server Components===<br /> <br /> *[[durchcoderd]]<br /> *[[herrd]]<br /> *[[rissd]]<br /> *[[seherd]]<br /> *[[unterhalterd]]<br /> <br /> ===Frontend/Client Components===<br /> <br /> *[[nackt]]<br /> *[[spieler]]<br /> *[[wunscher]]<br /> <br /> ===Database Design and Synchronization===<br /> <br /> *[[Tables]]<br /> *[[Managed Objects]]<br /> *[[Queues]]<br /> *[[Synchronization]]<br /> *[[Clients]]<br /> <br /> ===Components to Harness===<br /> <br /> *[[libgpod]]<br /> *[[vlc]]<br /> *[[mplayer]]<br /> *[[mpg123]]<br /> *[[mencoder]]<br /> *[[curses]]<br /> *[[ajax]]<br /> *[[firefox]]<br /> *[[wiimote mouse]]<br /> *[[tvshows from online]]<br /> *[http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites Auto deps for makefiles]<br /> *[http://www.fftw.org/doc/Complex-One_002dDimensional-DFTs.html fftw tutorial]<br /> *[http://en.wikipedia.org/wiki/Discrete_Fourier_transform stuff on DFT]<br /> *[http://www.grinninglizard.com/tinyxmldocs/index.html TinyXML]<br /> <br /> ===Other Related Projects===<br /> <br /> *[[bittorrent]]<br /> *[[blogging queue]]<br /> *[[mpr stream capture]]<br /> *[[photo management]]<br /> *[[email grabber]]<br /> *[[tag clouds]]<br /> *[[remote control device]]<br /> *[[dialup server system]]<br /> *[[distributed internal network]]<br /> *[[dvdlookup.org]]<br /> *[[playlist]]<br /> *[[slackpkg plus plus]]<br /> *[[gkrellm replacement]]<br /> *[[book cataloging]]<br /> *[[some avr stuff]]<br /> *[[modjs]]<br /> *[[thoughts on avr event scheduling]]<br /> *[[MIDI and the organ project]]<br /> *[[some sess doc stuff]]<br /> ----<br /> <br /> ===Stuff to get working on my computers===<br /> *[[xvmc]]<br /> *[[nis]]<br /> *[[proper dhcp]]<br /> *[[special fw on router]]</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Fernseher&diff=2149 2009-10-30T01:54:49Z

<p>Admin: </p> <hr /> <div>Fernseher is an all encompassing set of scripts to solve all the world&#039;s problems, determine whether P really does equal NP, make me lots of money, and make a fool of myself, all at once. I imagine it will be useful to no one, do exactly what no one wants it to do, and be accused of murder and money laundering multiple times. If it does what you want it to do, reconsider, because you are probably wrong. It won&#039;t even do what I want it to do, and I wrote the damn thing.<br /> <br /> In summation, your probably don&#039;t really want this set of crap on your box, and if you put it on your box, it is likely that your computer will implode, and almost certain that all your base will belong to me.<br /> <br /> That said, I am using this wiki to keep track of ideas I have for the various components involved, what they do, what they should do, how to use them, how to improve them, and what will happen if you don&#039;t use them with everything else. I am also hoping to do some rudimentary interface design here for the various front ends, as well as backend database design so I know how its all supposed to go together. I may also put any information I have on the various utilities I plan on using to interface with the tuner cards, as well as interfaces to play music and video, adjust channels, volume, use bittorrent, etc. <br /> <br /> *Festina lente (hurry slowly)<br /> *Id est (that is)<br /> <br /> ----<br /> ===Slackware resources===<br /> *slackware.com<br /> *slackbuilds.org<br /> *kernel.org<br /> *slackbook.org<br /> *slackwiki.org<br /> *sbopkg.org<br /> *linuxquestions.org<br /> *alienBOB&#039;s wiki<br /> *alienBOB&#039;s slackbuilds<br /> * ##slackware<br /> * #slackbuilds<br /> *slackware-annouce@slackware.com<br /> *slackware-security@slackware.com<br /> *slackbuilds-users@slackbuilds.org<br /> *linux-kernel@vger.kernel.org<br /> <br /> <br /> ===Backend/Server Components===<br /> <br /> *[[durchcoderd]]<br /> *[[herrd]]<br /> *[[rissd]]<br /> *[[seherd]]<br /> *[[unterhalterd]]<br /> <br /> ===Frontend/Client Components===<br /> <br /> *[[nackt]]<br /> *[[spieler]]<br /> *[[wunscher]]<br /> <br /> ===Database Design and Synchronization===<br /> <br /> *[[Tables]]<br /> *[[Managed Objects]]<br /> *[[Queues]]<br /> *[[Synchronization]]<br /> *[[Clients]]<br /> <br /> ===Components to Harness===<br /> <br /> *[[libgpod]]<br /> *[[vlc]]<br /> *[[mplayer]]<br /> *[[mpg123]]<br /> *[[mencoder]]<br /> *[[curses]]<br /> *[[ajax]]<br /> *[[firefox]]<br /> *[[wiimote mouse]]<br /> *[[tvshows from online]]<br /> *[http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites Auto deps for makefiles]<br /> *[http://www.fftw.org/doc/Complex-One_002dDimensional-DFTs.html fftw tutorial]<br /> *[http://en.wikipedia.org/wiki/Discrete_Fourier_transform stuff on DFT]<br /> *[http://www.grinninglizard.com/tinyxmldocs/index.html TinyXML]<br /> <br /> ===Other Related Projects===<br /> <br /> *[[bittorrent]]<br /> *[[blogging queue]]<br /> *[[mpr stream capture]]<br /> *[[photo management]]<br /> *[[email grabber]]<br /> *[[tag clouds]]<br /> *[[remote control device]]<br /> *[[dialup server system]]<br /> *[[distributed internal network]]<br /> *[[dvdlookup.org]]<br /> *[[playlist]]<br /> *[[slackpkg plus plus]]<br /> *[[gkrellm replacement]]<br /> *[[book cataloging]]<br /> *[[some avr stuff]]<br /> *[[modjs]]<br /> *[[thoughs on avr event scheduling]]<br /> *[[MIDI and the organ project]]<br /> ----<br /> <br /> ===Stuff to get working on my computers===<br /> *[[xvmc]]<br /> *[[nis]]<br /> *[[proper dhcp]]<br /> *[[special fw on router]]</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Fernseher&diff=2148 2009-10-30T01:54:21Z

<p>Admin: </p> <hr /> <div>Fernseher is an all encompassing set of scripts to solve all the world&#039;s problems, determine whether P really does equal NP, make me lots of money, and make a fool of myself, all at once. I imagine it will be useful to no one, do exactly what no one wants it to do, and be accused of murder and money laundering multiple times. If it does what you want it to do, reconsider, because you are probably wrong. It won&#039;t even do what I want it to do, and I wrote the damn thing.<br /> <br /> In summation, your probably don&#039;t really want this set of crap on your box, and if you put it on your box, it is likely that your computer will implode, and almost certain that all your base will belong to me.<br /> <br /> That said, I am using this wiki to keep track of ideas I have for the various components involved, what they do, what they should do, how to use them, how to improve them, and what will happen if you don&#039;t use them with everything else. I am also hoping to do some rudimentary interface design here for the various front ends, as well as backend database design so I know how its all supposed to go together. I may also put any information I have on the various utilities I plan on using to interface with the tuner cards, as well as interfaces to play music and video, adjust channels, volume, use bittorrent, etc. <br /> <br /> *Festina lente (hurry slowly)<br /> *Id est (that is)<br /> <br /> ----<br /> ===Slackware resources===<br /> *slackware.com<br /> *slackbuilds.org<br /> *kernel.org<br /> *slackbook.org<br /> *slackwiki.org<br /> *sbopkg.org<br /> *linuxquestions.org<br /> *alienBOB&#039;s wiki<br /> *alienBOB&#039;s slackbuilds<br /> *##slackware<br /> *#slackbuilds<br /> *slackware-annouce@slackware.com<br /> *slackware-security@slackware.com<br /> *slackbuilds-users@slackbuilds.org<br /> *linux-kernel@vger.kernel.org<br /> <br /> <br /> ===Backend/Server Components===<br /> <br /> *[[durchcoderd]]<br /> *[[herrd]]<br /> *[[rissd]]<br /> *[[seherd]]<br /> *[[unterhalterd]]<br /> <br /> ===Frontend/Client Components===<br /> <br /> *[[nackt]]<br /> *[[spieler]]<br /> *[[wunscher]]<br /> <br /> ===Database Design and Synchronization===<br /> <br /> *[[Tables]]<br /> *[[Managed Objects]]<br /> *[[Queues]]<br /> *[[Synchronization]]<br /> *[[Clients]]<br /> <br /> ===Components to Harness===<br /> <br /> *[[libgpod]]<br /> *[[vlc]]<br /> *[[mplayer]]<br /> *[[mpg123]]<br /> *[[mencoder]]<br /> *[[curses]]<br /> *[[ajax]]<br /> *[[firefox]]<br /> *[[wiimote mouse]]<br /> *[[tvshows from online]]<br /> *[http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites Auto deps for makefiles]<br /> *[http://www.fftw.org/doc/Complex-One_002dDimensional-DFTs.html fftw tutorial]<br /> *[http://en.wikipedia.org/wiki/Discrete_Fourier_transform stuff on DFT]<br /> *[http://www.grinninglizard.com/tinyxmldocs/index.html TinyXML]<br /> <br /> ===Other Related Projects===<br /> <br /> *[[bittorrent]]<br /> *[[blogging queue]]<br /> *[[mpr stream capture]]<br /> *[[photo management]]<br /> *[[email grabber]]<br /> *[[tag clouds]]<br /> *[[remote control device]]<br /> *[[dialup server system]]<br /> *[[distributed internal network]]<br /> *[[dvdlookup.org]]<br /> *[[playlist]]<br /> *[[slackpkg plus plus]]<br /> *[[gkrellm replacement]]<br /> *[[book cataloging]]<br /> *[[some avr stuff]]<br /> *[[modjs]]<br /> *[[thoughs on avr event scheduling]]<br /> *[[MIDI and the organ project]]<br /> ----<br /> <br /> ===Stuff to get working on my computers===<br /> *[[xvmc]]<br /> *[[nis]]<br /> *[[proper dhcp]]<br /> *[[special fw on router]]</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Bittorrent&diff=2147 2009-09-25T04:53:14Z

<p>Admin: </p> <hr /> <div>Use modules<br /> *XML::RSS::Parser::Lite<br /> *LWP::UserAgent<br /> *DBI<br /> *URI<br /> *HTML::Entities<br /> *HTML::TokeParser::Simple<br /> *WWW::Search::Mininova<br /> *Net::BitTorrent<br /> *POSIX qw(setsid)<br /> *[[http://www.koders.com/php/fidDC98117569020F0B3A6312EEA6D233B8550EA472.aspx]]<br /> <br /> daemonize<br /> set up sigint handler to set killflag<br /> connect to db<br /> set up torrent queue<br /> while not killflag<br /> processqueue<br /> if its been a second, checktorrentstates<br /> if its been a minute, checkfornewtorrents<br /> stop torrent queue<br /> checktorrentstates<br /> destroy torrent queue<br /> quit<br /> <br /> checkfornewtorrents:<br /> lock table<br /> get all torrents with state of torrentretrieved<br /> foreach new torrent<br /> add to queue and update torrent state<br /> unlock table<br /> <br /> checktorrentstates:<br /> lock table<br /> calculate stats for each torrent in the queue<br /> check if we were told to pause this torrent, if so, remove that torrent from the queue<br /> update the table with the latest stats.<br /> if necessary, remove from torrent queue. if not connected anymore, torrentretrieved/unconnected. If paused, paused/unconnected. If failed, torrentretrieved/unconnected.<br /> unlock table<br /> <br /> <br /> <br /> <br /> CUT!<br /> <br /> <br /> <br /> So, the idea was that some shows it might just be easier to get from Bittorrent than to wait for them to show up on television. Also, they are usually compressed better, are at higher quality, and usually have the commercials completely removed from them. So it would be nice if there was an easy way to see what could be gotten via Bittorrent. (Might also be useful to be able to get a list of episodes from places like wikipedia, with description, original air date, episode number, etc.)<br /> <br /> So, I need a way to access The Pirate Bay&#039;s database automatically. Recently, they have hinted at an API that will be useful for searching their database, but I can&#039;t currently find any details about that. For the time being, I may have to make my own HTML scraping version.<br /> <br /> ----<br /> <br /> http://thepiratebay.org/search.php?q=&lt;searchterms&gt;&amp;page=&lt;resultpagenum&gt;&amp;orderby=&lt;orderkey&gt;<br /> <br /> orderkey can be name, date, size, se, le<br /> page starts at 0.<br /> <br /> The table we want has an id of searchResult<br /> <br /> Thence follows a thead row, and then rows of results.<br /> <br /> Each result row is of form (has the following cells with examples):<br /> <br /> &lt;category link&gt;: &quot;&lt;a href=&quot;CATLINK&quot; title=&quot;More from this category&quot;&gt;CATEGORY&lt;/a&gt;&quot;<br /> <br /> &lt;detail link and title&gt;: &quot;&lt;a href=&quot;DESCLINK&quot; class=&quot;detLink&quot; title=&quot;Details for TITLE&quot;&gt;TITLE&lt;/a&gt;&quot;<br /> <br /> &lt;date and time of upload&gt;: &quot;DATE&amp;amp;nbsp;TIME&quot;<br /> <br /> &lt;download link&gt;: &quot;&lt;a href=&quot;DLLINK&quot; title=&quot;Download this torrent&quot;&gt;&lt;img src=&quot;IMGLINK&quot; class=&quot;dl&quot; alt=&quot;Download&quot; /&gt;&lt;/a&gt;&quot;<br /> <br /> &lt;size&gt;: &quot;SIZENUM&amp;amp;nbsp;SIZEUNIT&quot;<br /> <br /> &lt;seeders&gt;: &quot;SENUM&quot;<br /> <br /> &lt;leachers&gt;: &quot;LENUM&quot;<br /> <br /> So, from that, we want to extract CATEGORY, TITLE, DATE, TIME, DLLINK, SIZENUM, SIZEUNIT, SENUM, LENUM. Should be a cinch.<br /> <br /> The last row is empty in the source, but gets magically javascriptally filled in to be the page selector. I wouldn&#039;t worry about it for now.<br /> <br /> Note that all of this is likely to change as The Pirate Bay changes how they do things to be more AJAXy and APIy. Hopefully when that occurs, this will all fail gracefully, we&#039;ll know, and we can fix it to use the new APIs.</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Bittorrent&diff=2146 2009-09-24T05:19:08Z

<p>Admin: </p> <hr /> <div>Use modules<br /> *XML::RSS::Parser::Lite<br /> *LWP::UserAgent<br /> *DBI<br /> *URI<br /> *HTML::Entities<br /> *HTML::TokeParser::Simple<br /> *WWW::Search::Mininova<br /> *Net::BitTorrent<br /> *POSIX qw(setsid)<br /> <br /> daemonize<br /> set up sigint handler to set killflag<br /> connect to db<br /> set up torrent queue<br /> while not killflag<br /> processqueue<br /> if its been a second, checktorrentstates<br /> if its been a minute, checkfornewtorrents<br /> stop torrent queue<br /> checktorrentstates<br /> destroy torrent queue<br /> quit<br /> <br /> checkfornewtorrents:<br /> lock table<br /> get all torrents with state of torrentretrieved<br /> foreach new torrent<br /> add to queue and update torrent state<br /> unlock table<br /> <br /> checktorrentstates:<br /> lock table<br /> calculate stats for each torrent in the queue<br /> check if we were told to pause this torrent, if so, remove that torrent from the queue<br /> update the table with the latest stats.<br /> if necessary, remove from torrent queue. if not connected anymore, torrentretrieved/unconnected. If paused, paused/unconnected. If failed, torrentretrieved/unconnected.<br /> unlock table<br /> <br /> <br /> <br /> <br /> CUT!<br /> <br /> <br /> <br /> So, the idea was that some shows it might just be easier to get from Bittorrent than to wait for them to show up on television. Also, they are usually compressed better, are at higher quality, and usually have the commercials completely removed from them. So it would be nice if there was an easy way to see what could be gotten via Bittorrent. (Might also be useful to be able to get a list of episodes from places like wikipedia, with description, original air date, episode number, etc.)<br /> <br /> So, I need a way to access The Pirate Bay&#039;s database automatically. Recently, they have hinted at an API that will be useful for searching their database, but I can&#039;t currently find any details about that. For the time being, I may have to make my own HTML scraping version.<br /> <br /> ----<br /> <br /> http://thepiratebay.org/search.php?q=&lt;searchterms&gt;&amp;page=&lt;resultpagenum&gt;&amp;orderby=&lt;orderkey&gt;<br /> <br /> orderkey can be name, date, size, se, le<br /> page starts at 0.<br /> <br /> The table we want has an id of searchResult<br /> <br /> Thence follows a thead row, and then rows of results.<br /> <br /> Each result row is of form (has the following cells with examples):<br /> <br /> &lt;category link&gt;: &quot;&lt;a href=&quot;CATLINK&quot; title=&quot;More from this category&quot;&gt;CATEGORY&lt;/a&gt;&quot;<br /> <br /> &lt;detail link and title&gt;: &quot;&lt;a href=&quot;DESCLINK&quot; class=&quot;detLink&quot; title=&quot;Details for TITLE&quot;&gt;TITLE&lt;/a&gt;&quot;<br /> <br /> &lt;date and time of upload&gt;: &quot;DATE&amp;amp;nbsp;TIME&quot;<br /> <br /> &lt;download link&gt;: &quot;&lt;a href=&quot;DLLINK&quot; title=&quot;Download this torrent&quot;&gt;&lt;img src=&quot;IMGLINK&quot; class=&quot;dl&quot; alt=&quot;Download&quot; /&gt;&lt;/a&gt;&quot;<br /> <br /> &lt;size&gt;: &quot;SIZENUM&amp;amp;nbsp;SIZEUNIT&quot;<br /> <br /> &lt;seeders&gt;: &quot;SENUM&quot;<br /> <br /> &lt;leachers&gt;: &quot;LENUM&quot;<br /> <br /> So, from that, we want to extract CATEGORY, TITLE, DATE, TIME, DLLINK, SIZENUM, SIZEUNIT, SENUM, LENUM. Should be a cinch.<br /> <br /> The last row is empty in the source, but gets magically javascriptally filled in to be the page selector. I wouldn&#039;t worry about it for now.<br /> <br /> Note that all of this is likely to change as The Pirate Bay changes how they do things to be more AJAXy and APIy. Hopefully when that occurs, this will all fail gracefully, we&#039;ll know, and we can fix it to use the new APIs.</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Bittorrent&diff=2145 2009-09-24T05:18:50Z

<p>Admin: </p> <hr /> <div>Use modules<br /> *XML::RSS::Parser::Lite<br /> *LWP::UserAgent<br /> *DBI<br /> *URI<br /> *HTML::Entities<br /> *HTML::TokeParser::Simple<br /> *WWW::Search::Mininova<br /> *Net::BitTorrent<br /> *POSIX qw(setsid)<br /> <br /> daemonize<br /> set up sigint handler to set killflag<br /> connect to db<br /> set up torrent queue<br /> while not killflag<br /> processqueue<br /> if its been a second, checktorrentstates<br /> if its been a minute, checkfornewtorrents<br /> stop torrent queue<br /> checktorrentstates<br /> destroy torrent queue<br /> quit<br /> <br /> checkfornewtorrents:<br /> lock table<br /> get all torrents with state of torrentretrieved<br /> foreach new torrent<br /> add to queue and update torrent state<br /> unlock table<br /> <br /> checktorrentstates:<br /> lock table<br /> calculate stats for each torrent in the queue<br /> check if we were told to pause this torrent, if so, remove that torrent from the queue<br /> update the table with the latest stats.<br /> if necessary, remove from torrent queue. if not connected anymore, torrentretrieved/unconnected. If paused, paused/unconnected. If failed, torrentretrieved/unconnected.<br /> unlock table<br /> <br /> <br /> <br /> <br /> CUT!<br /> <br /> <br /> <br /> So, the idea was that some shows it might just be easier to get from Bittorrent than to wait for them to show up on television. Also, they are usually compressed better, are at higher quality, and usually have the commercials completely removed from them. So it would be nice if there was an easy way to see what could be gotten via Bittorrent. (Might also be useful to be able to get a list of episodes from places like wikipedia, with description, original air date, episode number, etc.)<br /> <br /> So, I need a way to access The Pirate Bay&#039;s database automatically. Recently, they have hinted at an API that will be useful for searching their database, but I can&#039;t currently find any details about that. For the time being, I may have to make my own HTML scraping version.<br /> <br /> ----<br /> <br /> http://thepiratebay.org/search.php?q=&lt;searchterms&gt;&amp;page=&lt;resultpagenum&gt;&amp;orderby=&lt;orderkey&gt;<br /> <br /> orderkey can be name, date, size, se, le<br /> page starts at 0.<br /> <br /> The table we want has an id of searchResult<br /> <br /> Thence follows a thead row, and then rows of results.<br /> <br /> Each result row is of form (has the following cells with examples):<br /> <br /> &lt;category link&gt;: &quot;&lt;a href=&quot;CATLINK&quot; title=&quot;More from this category&quot;&gt;CATEGORY&lt;/a&gt;&quot;<br /> <br /> &lt;detail link and title&gt;: &quot;&lt;a href=&quot;DESCLINK&quot; class=&quot;detLink&quot; title=&quot;Details for TITLE&quot;&gt;TITLE&lt;/a&gt;&quot;<br /> <br /> &lt;date and time of upload&gt;: &quot;DATE&amp;amp;nbsp;TIME&quot;<br /> <br /> &lt;download link&gt;: &quot;&lt;a href=&quot;DLLINK&quot; title=&quot;Download this torrent&quot;&gt;&lt;img src=&quot;IMGLINK&quot; class=&quot;dl&quot; alt=&quot;Download&quot; /&gt;&lt;/a&gt;&quot;<br /> <br /> &lt;size&gt;: &quot;SIZENUM&amp;amp;nbsp;SIZEUNIT&quot;<br /> <br /> &lt;seeders&gt;: &quot;SENUM&quot;<br /> <br /> &lt;leachers&gt;: &quot;LENUM&quot;<br /> <br /> So, from that, we want to extract CATEGORY, TITLE, DATE, TIME, DLLINK, SIZENUM, SIZEUNIT, SENUM, LENUM. Should be a cinch.<br /> <br /> The last row is empty in the source, but gets magically javascriptally filled in to be the page selector. I wouldn&#039;t worry about it for now.<br /> <br /> Note that all of this is likely to change as The Pirate Bay changes how they do things to be more AJAXy and APIy. Hopefully when that occurs, this will all fail gracefully, we&#039;ll know, and we can fix it to use the new APIs.</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Fernseher&diff=2144 2009-05-27T22:41:13Z

<p>Admin: </p> <hr /> <div>Fernseher is an all encompassing set of scripts to solve all the world&#039;s problems, determine whether P really does equal NP, make me lots of money, and make a fool of myself, all at once. I imagine it will be useful to no one, do exactly what no one wants it to do, and be accused of murder and money laundering multiple times. If it does what you want it to do, reconsider, because you are probably wrong. It won&#039;t even do what I want it to do, and I wrote the damn thing.<br /> <br /> In summation, your probably don&#039;t really want this set of crap on your box, and if you put it on your box, it is likely that your computer will implode, and almost certain that all your base will belong to me.<br /> <br /> That said, I am using this wiki to keep track of ideas I have for the various components involved, what they do, what they should do, how to use them, how to improve them, and what will happen if you don&#039;t use them with everything else. I am also hoping to do some rudimentary interface design here for the various front ends, as well as backend database design so I know how its all supposed to go together. I may also put any information I have on the various utilities I plan on using to interface with the tuner cards, as well as interfaces to play music and video, adjust channels, volume, use bittorrent, etc. <br /> <br /> *Festina lente (hurry slowly)<br /> *Id est (that is)<br /> <br /> ----<br /> ===Backend/Server Components===<br /> <br /> *[[durchcoderd]]<br /> *[[herrd]]<br /> *[[rissd]]<br /> *[[seherd]]<br /> *[[unterhalterd]]<br /> <br /> ===Frontend/Client Components===<br /> <br /> *[[nackt]]<br /> *[[spieler]]<br /> *[[wunscher]]<br /> <br /> ===Database Design and Synchronization===<br /> <br /> *[[Tables]]<br /> *[[Managed Objects]]<br /> *[[Queues]]<br /> *[[Synchronization]]<br /> *[[Clients]]<br /> <br /> ===Components to Harness===<br /> <br /> *[[libgpod]]<br /> *[[vlc]]<br /> *[[mplayer]]<br /> *[[mpg123]]<br /> *[[mencoder]]<br /> *[[curses]]<br /> *[[ajax]]<br /> *[[firefox]]<br /> *[[wiimote mouse]]<br /> *[[tvshows from online]]<br /> *[http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites Auto deps for makefiles]<br /> *[http://www.fftw.org/doc/Complex-One_002dDimensional-DFTs.html fftw tutorial]<br /> *[http://en.wikipedia.org/wiki/Discrete_Fourier_transform stuff on DFT]<br /> *[http://www.grinninglizard.com/tinyxmldocs/index.html TinyXML]<br /> <br /> ===Other Related Projects===<br /> <br /> *[[bittorrent]]<br /> *[[blogging queue]]<br /> *[[mpr stream capture]]<br /> *[[photo management]]<br /> *[[email grabber]]<br /> *[[tag clouds]]<br /> *[[remote control device]]<br /> *[[dialup server system]]<br /> *[[distributed internal network]]<br /> *[[dvdlookup.org]]<br /> *[[playlist]]<br /> *[[slackpkg plus plus]]<br /> *[[gkrellm replacement]]<br /> *[[book cataloging]]<br /> *[[some avr stuff]]<br /> *[[modjs]]<br /> *[[thoughs on avr event scheduling]]<br /> *[[MIDI and the organ project]]<br /> ----<br /> <br /> ===Stuff to get working on my computers===<br /> *[[xvmc]]<br /> *[[nis]]<br /> *[[proper dhcp]]<br /> *[[special fw on router]]</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Fernseher&diff=2135 2009-03-07T04:35:05Z

<p>Admin: /* Components to Harness */</p> <hr /> <div>Fernseher is an all encompassing set of scripts to solve all the world&#039;s problems, determine whether P really does equal NP, make me lots of money, and make a fool of myself, all at once. I imagine it will be useful to no one, do exactly what no one wants it to do, and be accused of murder and money laundering multiple times. If it does what you want it to do, reconsider, because you are probably wrong. It won&#039;t even do what I want it to do, and I wrote the damn thing.<br /> <br /> In summation, your probably don&#039;t really want this set of crap on your box, and if you put it on your box, it is likely that your computer will implode, and almost certain that all your base will belong to me.<br /> <br /> That said, I am using this wiki to keep track of ideas I have for the various components involved, what they do, what they should do, how to use them, how to improve them, and what will happen if you don&#039;t use them with everything else. I am also hoping to do some rudimentary interface design here for the various front ends, as well as backend database design so I know how its all supposed to go together. I may also put any information I have on the various utilities I plan on using to interface with the tuner cards, as well as interfaces to play music and video, adjust channels, volume, use bittorrent, etc. <br /> <br /> ----<br /> ===Backend/Server Components===<br /> <br /> *[[durchcoderd]]<br /> *[[herrd]]<br /> *[[rissd]]<br /> *[[seherd]]<br /> *[[unterhalterd]]<br /> <br /> ===Frontend/Client Components===<br /> <br /> *[[nackt]]<br /> *[[spieler]]<br /> *[[wunscher]]<br /> <br /> ===Database Design and Synchronization===<br /> <br /> *[[Tables]]<br /> *[[Managed Objects]]<br /> *[[Queues]]<br /> *[[Synchronization]]<br /> *[[Clients]]<br /> <br /> ===Components to Harness===<br /> <br /> *[[libgpod]]<br /> *[[vlc]]<br /> *[[mplayer]]<br /> *[[mpg123]]<br /> *[[mencoder]]<br /> *[[curses]]<br /> *[[ajax]]<br /> *[[firefox]]<br /> *[[wiimote mouse]]<br /> *[[tvshows from online]]<br /> *[http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites Auto deps for makefiles]<br /> *[http://www.fftw.org/doc/Complex-One_002dDimensional-DFTs.html fftw tutorial]<br /> *[http://en.wikipedia.org/wiki/Discrete_Fourier_transform stuff on DFT]<br /> *[http://www.grinninglizard.com/tinyxmldocs/index.html TinyXML]<br /> <br /> ===Other Related Projects===<br /> <br /> *[[bittorrent]]<br /> *[[blogging queue]]<br /> *[[mpr stream capture]]<br /> *[[photo management]]<br /> *[[email grabber]]<br /> *[[tag clouds]]<br /> *[[remote control device]]<br /> *[[dialup server system]]<br /> *[[distributed internal network]]<br /> *[[dvdlookup.org]]<br /> *[[playlist]]<br /> *[[slackpkg plus plus]]<br /> *[[gkrellm replacement]]<br /> *[[book cataloging]]<br /> *[[some avr stuff]]<br /> *[[modjs]]<br /> *[[thoughs on avr event scheduling]]<br /> *[[MIDI and the organ project]]<br /> ----<br /> <br /> ===Stuff to get working on my computers===<br /> *[[xvmc]]<br /> *[[nis]]<br /> *[[proper dhcp]]<br /> *[[special fw on router]]</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Fernseher&diff=2134 2009-03-06T06:47:55Z

<p>Admin: /* Components to Harness */</p> <hr /> <div>Fernseher is an all encompassing set of scripts to solve all the world&#039;s problems, determine whether P really does equal NP, make me lots of money, and make a fool of myself, all at once. I imagine it will be useful to no one, do exactly what no one wants it to do, and be accused of murder and money laundering multiple times. If it does what you want it to do, reconsider, because you are probably wrong. It won&#039;t even do what I want it to do, and I wrote the damn thing.<br /> <br /> In summation, your probably don&#039;t really want this set of crap on your box, and if you put it on your box, it is likely that your computer will implode, and almost certain that all your base will belong to me.<br /> <br /> That said, I am using this wiki to keep track of ideas I have for the various components involved, what they do, what they should do, how to use them, how to improve them, and what will happen if you don&#039;t use them with everything else. I am also hoping to do some rudimentary interface design here for the various front ends, as well as backend database design so I know how its all supposed to go together. I may also put any information I have on the various utilities I plan on using to interface with the tuner cards, as well as interfaces to play music and video, adjust channels, volume, use bittorrent, etc. <br /> <br /> ----<br /> ===Backend/Server Components===<br /> <br /> *[[durchcoderd]]<br /> *[[herrd]]<br /> *[[rissd]]<br /> *[[seherd]]<br /> *[[unterhalterd]]<br /> <br /> ===Frontend/Client Components===<br /> <br /> *[[nackt]]<br /> *[[spieler]]<br /> *[[wunscher]]<br /> <br /> ===Database Design and Synchronization===<br /> <br /> *[[Tables]]<br /> *[[Managed Objects]]<br /> *[[Queues]]<br /> *[[Synchronization]]<br /> *[[Clients]]<br /> <br /> ===Components to Harness===<br /> <br /> *[[libgpod]]<br /> *[[vlc]]<br /> *[[mplayer]]<br /> *[[mpg123]]<br /> *[[mencoder]]<br /> *[[curses]]<br /> *[[ajax]]<br /> *[[firefox]]<br /> *[[wiimote mouse]]<br /> *[[tvshows from online]]<br /> *[http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites Auto deps for makefiles]<br /> *[http://www.fftw.org/doc/Complex-One_002dDimensional-DFTs.html fftw tutorial]<br /> *[http://en.wikipedia.org/wiki/Discrete_Fourier_transform stuff on DFT]<br /> <br /> ===Other Related Projects===<br /> <br /> *[[bittorrent]]<br /> *[[blogging queue]]<br /> *[[mpr stream capture]]<br /> *[[photo management]]<br /> *[[email grabber]]<br /> *[[tag clouds]]<br /> *[[remote control device]]<br /> *[[dialup server system]]<br /> *[[distributed internal network]]<br /> *[[dvdlookup.org]]<br /> *[[playlist]]<br /> *[[slackpkg plus plus]]<br /> *[[gkrellm replacement]]<br /> *[[book cataloging]]<br /> *[[some avr stuff]]<br /> *[[modjs]]<br /> *[[thoughs on avr event scheduling]]<br /> *[[MIDI and the organ project]]<br /> ----<br /> <br /> ===Stuff to get working on my computers===<br /> *[[xvmc]]<br /> *[[nis]]<br /> *[[proper dhcp]]<br /> *[[special fw on router]]</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Fernseher&diff=2133 2009-03-06T06:47:06Z

<p>Admin: </p> <hr /> <div>Fernseher is an all encompassing set of scripts to solve all the world&#039;s problems, determine whether P really does equal NP, make me lots of money, and make a fool of myself, all at once. I imagine it will be useful to no one, do exactly what no one wants it to do, and be accused of murder and money laundering multiple times. If it does what you want it to do, reconsider, because you are probably wrong. It won&#039;t even do what I want it to do, and I wrote the damn thing.<br /> <br /> In summation, your probably don&#039;t really want this set of crap on your box, and if you put it on your box, it is likely that your computer will implode, and almost certain that all your base will belong to me.<br /> <br /> That said, I am using this wiki to keep track of ideas I have for the various components involved, what they do, what they should do, how to use them, how to improve them, and what will happen if you don&#039;t use them with everything else. I am also hoping to do some rudimentary interface design here for the various front ends, as well as backend database design so I know how its all supposed to go together. I may also put any information I have on the various utilities I plan on using to interface with the tuner cards, as well as interfaces to play music and video, adjust channels, volume, use bittorrent, etc. <br /> <br /> ----<br /> ===Backend/Server Components===<br /> <br /> *[[durchcoderd]]<br /> *[[herrd]]<br /> *[[rissd]]<br /> *[[seherd]]<br /> *[[unterhalterd]]<br /> <br /> ===Frontend/Client Components===<br /> <br /> *[[nackt]]<br /> *[[spieler]]<br /> *[[wunscher]]<br /> <br /> ===Database Design and Synchronization===<br /> <br /> *[[Tables]]<br /> *[[Managed Objects]]<br /> *[[Queues]]<br /> *[[Synchronization]]<br /> *[[Clients]]<br /> <br /> ===Components to Harness===<br /> <br /> *[[libgpod]]<br /> *[[vlc]]<br /> *[[mplayer]]<br /> *[[mpg123]]<br /> *[[mencoder]]<br /> *[[curses]]<br /> *[[ajax]]<br /> *[[firefox]]<br /> *[[wiimote mouse]]<br /> *[[tvshows from online]]<br /> *[http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites Auto deps for makefiles]<br /> <br /> ===Other Related Projects===<br /> <br /> *[[bittorrent]]<br /> *[[blogging queue]]<br /> *[[mpr stream capture]]<br /> *[[photo management]]<br /> *[[email grabber]]<br /> *[[tag clouds]]<br /> *[[remote control device]]<br /> *[[dialup server system]]<br /> *[[distributed internal network]]<br /> *[[dvdlookup.org]]<br /> *[[playlist]]<br /> *[[slackpkg plus plus]]<br /> *[[gkrellm replacement]]<br /> *[[book cataloging]]<br /> *[[some avr stuff]]<br /> *[[modjs]]<br /> *[[thoughs on avr event scheduling]]<br /> *[[MIDI and the organ project]]<br /> ----<br /> <br /> ===Stuff to get working on my computers===<br /> *[[xvmc]]<br /> *[[nis]]<br /> *[[proper dhcp]]<br /> *[[special fw on router]]</div>

Admin http://sessrumnir.net/fernseher/index.php?title=MIDI_and_the_organ_project&diff=2126 2009-02-27T22:26:37Z

<p>Admin: </p> <hr /> <div>*[http://sessrumnir.net/organs/trunk/ SVN trunk for organ code]<br /> <br /> <br /> ====MIDI and the organ====<br /> MIDI standard is out there. Also good is the RTP-MIDI RFC, for putting MIDI data into a stream and whatnot.<br /> <br /> The basics, as I think we will be using them:<br /> <br /> Packet basics (we&#039;ll only be using 3 byte packet forms):<br /> <br /> 1 &lt;3: opcode&gt; &lt;4: channel&gt; 0 &lt;7: arg1&gt; 0 &lt;7: arg2&gt;<br /> <br /> Essentially, a status byte, with the high bit on (0x80-0xFF), and two argument bytes, with the high bit off (0x00-0x7F).<br /> <br /> opcodes of relevance:<br /> *0x0: key off. arg1 is the key number, arg2 is the velocity. We will always use velocity of 0x40.<br /> *0x1: key on. arg1 is the key number, arg2 is the velocity. We will always use the velocity of 0x40.<br /> *0x3: control change. arg1 is the control number (0x01 is modulation wheel, 0x0B is the expression pedal), arg2 is the new control value, from 0x00 - 0x7F (Note: If we need more than 127 steps, add 0x20 to the control number, and thats the control number to use to send the least significant 7-bits of the value. The value sent with the base control number is considered to be the most significant 7-bits of the value. This ensures that if just read the base control number, you set the control to approximately the correct percentage of fully off/fully on.)<br /> <br /> For channels, we will use:<br /> *0x0: Great (Solo) Manual<br /> *0x1: Swell (Accompaniment) Manual<br /> *0x2: Choir (below Great) Manual, if present<br /> *0x3: Solo (above Swell) Manual, if present<br /> *0x4: Echo (above Solo) Manual, if present<br /> *0x5: Third Pedalboard, if present, or the auxilary stop channel, covering additional stops for all manuals and pedals.<br /> *0x6: Second Pedalboard, if present, or the main stop channel, covering all stops for all manuals and pedals.<br /> *0x7: Main Pedalboard<br /> *0x8: Great stops only<br /> *0x9: Swell stops only<br /> *0xA: Choir stops only<br /> *0xB: Solo stops only<br /> *0xC: Echo stops only<br /> *0xD: Third Pedalboard stops only<br /> *0xE: Second Pedalboard stops only<br /> *0xF: Main Pedalboard stops only<br /> <br /> Our initial organ will only use channels 0x0-0x1, 0x6-0x7.<br /> <br /> Each keyboard channel (0x0-0x7) gets its own control set. For our organ, where the modulation wheel and expression pedal control all divisions equally, each control change gets sent for each active channel... or maybe just for great, and the software will figure out that they control all the stuff. Note, we may not hook up the modulation wheel when we begin. It&#039;d be kinda a lot harder to make work right, I think.<br /> <br /> We will be building channel combination boards, that take an enable and a sub-channel address, and read back the contents of the addressed buffer. 4 bits of address gets 16 buffers. At 8 bits per buffer, thats 128 inputs for each channel. That matches with midi&#039;s numbering scheme. Alternatively, if you take the LSB of the true channel, and feed it to the 4th address bit of the channel board, and only decode the top 3 bits of the channel to determine channel board enable, you can duplex your channel boards, since we will only be using under 64 inputs per channel. The AVR firmware will have an MIDI offset value for each channel to add to the number received from the board before sending as part of a MIDI command. For most subchannels, this will be 36. Will probably just use an offset of 0 for the stop channels.<br /> <br /> Using the split channel board design, we only need two channel boards for our organ. The main board will be designed to use the channel boards in split mode, and will never probably use the split-mode stop channels (0x8-0xF), so it will only have 4 plugs for channel boards, 0x0-0x1, 0x2-0x3, 0x4-0x5, and 0x6-0x7. The initial organ will only use the first and last of these plugs, so we don&#039;t even need to populate the board positions for the other channel boards.<br /> <br /> Also, I think we might want to put all the switch pull-up resistors on the manuals themselves, soldered to the key tabs. This will eliminate a lot of crap on the boards, and keep the board design uniform, since the different keys will need different pull-ups. The manuals, with their 5k internal resistance, will need 50k (or so) pull-ups to 5V, and the pedals and stops, with no internal resistance, will need just 10k (or so) pull-ups to 5V. Each manual will get a separate power and ground plug for the pull-ups and grounds, so the connectors for the keys don&#039;t need a pin for ground or power, I don&#039;t think... Though if there is room, I guess we could send it along there, too. Can&#039;t hurt anything, provided the wires support enough current for the crazy case of all the stop pulled or keys pressed or something. Given a max of 64 inputs to a half-channel, and only 61 keys on a full manual, we can use 2x36 pin connectors for the manuals, and 1x36 pin connector for the pedalboards, and 1x36 pin connector for the stop boards. Thats 6 total 36 pin connectors, male and female, solder cup and through-hole.<br /> <br /> Channel board to main board connectors will have an 8-bit data bus, 4-bit address bus, a power, ground, enable, and identify(?) pins (16 total). Should be able to use IDC connectors and ribbon cable here.<br /> <br /> ===Simple algorithm for key change detection===<br /> After reading a byte from the buffers, we xor it with the copy of the byte from last time, then store the new version in the copy location. We then start looking at the lsb of the xor&#039;ed byte. If its a 1, we send a key on if the lsb of the read byte is a 1, and a key off if the lsb of the read byte is a 0. We then shift right and do that again. We do that 8 times, once for each bit in that byte. Then we can move on to the next valid address for that channel, write out the address, read back the buffer value, xor, store, analyze, etc. Note, we can speed this up by checking if the xor byte is identically 0x00, in which case we don&#039;t have to analyze it, it hasn&#039;t changed. This will be the usual case! Only occasionally (in sample time), will things change, and usually only on one bit, and thus one buffer, amongst all the channels and buffers. This should help us keep up to speed.<br /> <br /> Once we are done reading all the channel board buffers, we can check the expression pedals and other variable controls for new values, and possibly send control change events. After all this, we actually send the MIDI bytes as we have determined them to need to be for this time around, and go to sleep until our next sample time.<br /> <br /> Not sure what the latency of the serial to USB conversion is in FTDI, but it could be as bad as a single byte in a single USB message.... Anyway, we want to build a buffer of bytes that need to get send over each sample time, with the RTP-MIDI spec used to make it a stream type thing. This means: packet length, &quot;timestamp&quot;, first MIDI event, relative timestamps (should all be zero), subsequent MIDI events.<br /> <br /> ===Chips to use===<br /> *16x? 74HCT540 for the octal tri-state buffers, inverting (0.54, 20 pin dip)<br /> *1x? 74HCT138 for 1 to 8 decoder (0.40, 16 pin dip)<br /> *1x? 74HCT154 for 1 to 16 decoder (0.80, 24 pin dip)<br /> *1x ATMega164P-20P for AVR controller, 20MHz, (4.82, 40 pin dip)</div>

Admin http://sessrumnir.net/fernseher/index.php?title=MIDI_and_the_organ_project&diff=2123 2009-02-23T05:06:37Z

<p>Admin: </p> <hr /> <div>MIDI standard is out there. Also good is the RTP-MIDI RFC, for putting MIDI data into a stream and whatnot.<br /> <br /> The basics, as I think we will be using them:<br /> <br /> Packet basics (we&#039;ll only be using 3 byte packet forms):<br /> <br /> 1 &lt;3: opcode&gt; &lt;4: channel&gt; 0 &lt;7: arg1&gt; 0 &lt;7: arg2&gt;<br /> <br /> Essentially, a status byte, with the high bit on (0x80-0xFF), and two argument bytes, with the high bit off (0x00-0x7F).<br /> <br /> opcodes of relevance:<br /> *0x0: key off. arg1 is the key number, arg2 is the velocity. We will always use velocity of 0x40.<br /> *0x1: key on. arg1 is the key number, arg2 is the velocity. We will always use the velocity of 0x40.<br /> *0x3: control change. arg1 is the control number (0x01 is modulation wheel, 0x0B is the expression pedal), arg2 is the new control value, from 0x00 - 0x7F (Note: If we need more than 127 steps, add 0x20 to the control number, and thats the control number to use to send the least significant 7-bits of the value. The value sent with the base control number is considered to be the most significant 7-bits of the value. This ensures that if just read the base control number, you set the control to approximately the correct percentage of fully off/fully on.)<br /> <br /> For channels, we will use:<br /> *0x0: Great (Solo) Manual<br /> *0x1: Swell (Accompaniment) Manual<br /> *0x2: Choir (below Great) Manual, if present<br /> *0x3: Solo (above Swell) Manual, if present<br /> *0x4: Echo (above Solo) Manual, if present<br /> *0x5: Third Pedalboard, if present, or the auxilary stop channel, covering additional stops for all manuals and pedals.<br /> *0x6: Second Pedalboard, if present, or the main stop channel, covering all stops for all manuals and pedals.<br /> *0x7: Main Pedalboard<br /> *0x8: Great stops only<br /> *0x9: Swell stops only<br /> *0xA: Choir stops only<br /> *0xB: Solo stops only<br /> *0xC: Echo stops only<br /> *0xD: Third Pedalboard stops only<br /> *0xE: Second Pedalboard stops only<br /> *0xF: Main Pedalboard stops only<br /> <br /> Our initial organ will only use channels 0x0-0x1, 0x6-0x7.<br /> <br /> Each keyboard channel (0x0-0x7) gets its own control set. For our organ, where the modulation wheel and expression pedal control all divisions equally, each control change gets sent for each active channel... or maybe just for great, and the software will figure out that they control all the stuff. Note, we may not hook up the modulation wheel when we begin. It&#039;d be kinda a lot harder to make work right, I think.<br /> <br /> We will be building channel combination boards, that take an enable and a sub-channel address, and read back the contents of the addressed buffer. 4 bits of address gets 16 buffers. At 8 bits per buffer, thats 128 inputs for each channel. That matches with midi&#039;s numbering scheme. Alternatively, if you take the LSB of the true channel, and feed it to the 4th address bit of the channel board, and only decode the top 3 bits of the channel to determine channel board enable, you can duplex your channel boards, since we will only be using under 64 inputs per channel. The AVR firmware will have an MIDI offset value for each channel to add to the number received from the board before sending as part of a MIDI command. For most subchannels, this will be 36. Will probably just use an offset of 0 for the stop channels.<br /> <br /> Using the split channel board design, we only need two channel boards for our organ. The main board will be designed to use the channel boards in split mode, and will never probably use the split-mode stop channels (0x8-0xF), so it will only have 4 plugs for channel boards, 0x0-0x1, 0x2-0x3, 0x4-0x5, and 0x6-0x7. The initial organ will only use the first and last of these plugs, so we don&#039;t even need to populate the board positions for the other channel boards.<br /> <br /> Also, I think we might want to put all the switch pull-up resistors on the manuals themselves, soldered to the key tabs. This will eliminate a lot of crap on the boards, and keep the board design uniform, since the different keys will need different pull-ups. The manuals, with their 5k internal resistance, will need 50k (or so) pull-ups to 5V, and the pedals and stops, with no internal resistance, will need just 10k (or so) pull-ups to 5V. Each manual will get a separate power and ground plug for the pull-ups and grounds, so the connectors for the keys don&#039;t need a pin for ground or power, I don&#039;t think... Though if there is room, I guess we could send it along there, too. Can&#039;t hurt anything, provided the wires support enough current for the crazy case of all the stop pulled or keys pressed or something. Given a max of 64 inputs to a half-channel, and only 61 keys on a full manual, we can use 2x36 pin connectors for the manuals, and 1x36 pin connector for the pedalboards, and 1x36 pin connector for the stop boards. Thats 6 total 36 pin connectors, male and female, solder cup and through-hole.<br /> <br /> Channel board to main board connectors will have an 8-bit data bus, 4-bit address bus, a power, ground, enable, and identify(?) pins (16 total). Should be able to use IDC connectors and ribbon cable here.<br /> <br /> ===Simple algorithm for key change detection===<br /> After reading a byte from the buffers, we xor it with the copy of the byte from last time, then store the new version in the copy location. We then start looking at the lsb of the xor&#039;ed byte. If its a 1, we send a key on if the lsb of the read byte is a 1, and a key off if the lsb of the read byte is a 0. We then shift right and do that again. We do that 8 times, once for each bit in that byte. Then we can move on to the next valid address for that channel, write out the address, read back the buffer value, xor, store, analyze, etc. Note, we can speed this up by checking if the xor byte is identically 0x00, in which case we don&#039;t have to analyze it, it hasn&#039;t changed. This will be the usual case! Only occasionally (in sample time), will things change, and usually only on one bit, and thus one buffer, amongst all the channels and buffers. This should help us keep up to speed.<br /> <br /> Once we are done reading all the channel board buffers, we can check the expression pedals and other variable controls for new values, and possibly send control change events. After all this, we actually send the MIDI bytes as we have determined them to need to be for this time around, and go to sleep until our next sample time.<br /> <br /> Not sure what the latency of the serial to USB conversion is in FTDI, but it could be as bad as a single byte in a single USB message.... Anyway, we want to build a buffer of bytes that need to get send over each sample time, with the RTP-MIDI spec used to make it a stream type thing. This means: packet length, &quot;timestamp&quot;, first MIDI event, relative timestamps (should all be zero), subsequent MIDI events.</div>

Admin http://sessrumnir.net/fernseher/index.php?title=MIDI_and_the_organ_project&diff=2122 2009-02-23T05:02:22Z

<p>Admin: </p> <hr /> <div>MIDI standard is out there. Also good is the RTP-MIDI RFC, for putting MIDI data into a stream and whatnot.<br /> <br /> The basics, as I think we will be using them:<br /> <br /> Packet basics (we&#039;ll only be using 3 byte packet forms):<br /> <br /> 1 &lt;3: opcode&gt; &lt;4: channel&gt; 0 &lt;7: arg1&gt; 0 &lt;7: arg2&gt;<br /> <br /> Essentially, a status byte, with the high bit on (0x80-0xFF), and two argument bytes, with the high bit off (0x00-0x7F).<br /> <br /> opcodes of relevance:<br /> *0x0: key off. arg1 is the key number, arg2 is the velocity. We will always use velocity of 0x40.<br /> *0x1: key on. arg1 is the key number, arg2 is the velocity. We will always use the velocity of 0x40.<br /> *0x3: control change. arg1 is the control number (0x01 is modulation wheel, 0x0B is the expression pedal), arg2 is the new control value, from 0x00 - 0x7F<br /> <br /> For channels, we will use:<br /> *0x0: Great (Solo) Manual<br /> *0x1: Swell (Accompaniment) Manual<br /> *0x2: Choir (below Great) Manual, if present<br /> *0x3: Solo (above Swell) Manual, if present<br /> *0x4: Echo (above Solo) Manual, if present<br /> *0x5: Third Pedalboard, if present, or the auxilary stop channel, covering additional stops for all manuals and pedals.<br /> *0x6: Second Pedalboard, if present, or the main stop channel, covering all stops for all manuals and pedals.<br /> *0x7: Main Pedalboard<br /> *0x8: Great stops only<br /> *0x9: Swell stops only<br /> *0xA: Choir stops only<br /> *0xB: Solo stops only<br /> *0xC: Echo stops only<br /> *0xD: Third Pedalboard stops only<br /> *0xE: Second Pedalboard stops only<br /> *0xF: Main Pedalboard stops only<br /> <br /> Our initial organ will only use channels 0x0-0x1, 0x6-0x7.<br /> <br /> Each keyboard channel (0x0-0x7) gets its own control set. For our organ, where the modulation wheel and expression pedal control all divisions equally, each control change gets sent for each active channel... or maybe just for great, and the software will figure out that they control all the stuff. Note, we may not hook up the modulation wheel when we begin. It&#039;d be kinda a lot harder to make work right, I think.<br /> <br /> We will be building channel combination boards, that take an enable and a sub-channel address, and read back the contents of the addressed buffer. 4 bits of address gets 16 buffers. At 8 bits per buffer, thats 128 inputs for each channel. That matches with midi&#039;s numbering scheme. Alternatively, if you take the LSB of the true channel, and feed it to the 4th address bit of the channel board, and only decode the top 3 bits of the channel to determine channel board enable, you can duplex your channel boards, since we will only be using under 64 inputs per channel. The AVR firmware will have an MIDI offset value for each channel to add to the number received from the board before sending as part of a MIDI command. For most subchannels, this will be 36. Will probably just use an offset of 0 for the stop channels.<br /> <br /> Using the split channel board design, we only need two channel boards for our organ. The main board will be designed to use the channel boards in split mode, and will never probably use the split-mode stop channels (0x8-0xF), so it will only have 4 plugs for channel boards, 0x0-0x1, 0x2-0x3, 0x4-0x5, and 0x6-0x7. The initial organ will only use the first and last of these plugs, so we don&#039;t even need to populate the board positions for the other channel boards.<br /> <br /> Also, I think we might want to put all the switch pull-up resistors on the manuals themselves, soldered to the key tabs. This will eliminate a lot of crap on the boards, and keep the board design uniform, since the different keys will need different pull-ups. The manuals, with their 5k internal resistance, will need 50k (or so) pull-ups to 5V, and the pedals and stops, with no internal resistance, will need just 10k (or so) pull-ups to 5V. Each manual will get a separate power and ground plug for the pull-ups and grounds, so the connectors for the keys don&#039;t need a pin for ground or power, I don&#039;t think... Though if there is room, I guess we could send it along there, too. Can&#039;t hurt anything, provided the wires support enough current for the crazy case of all the stop pulled or keys pressed or something. Given a max of 64 inputs to a half-channel, and only 61 keys on a full manual, we can use 2x36 pin connectors for the manuals, and 1x36 pin connector for the pedalboards, and 1x36 pin connector for the stop boards. Thats 6 total 36 pin connectors, male and female, solder cup and through-hole.<br /> <br /> Channel board to main board connectors will have an 8-bit data bus, 4-bit address bus, a power, ground, enable, and identify(?) pins (16 total). Should be able to use IDC connectors and ribbon cable here.<br /> <br /> ===Simple algorithm for key change detection===<br /> After reading a byte from the buffers, we xor it with the copy of the byte from last time, then store the new version in the copy location. We then start looking at the lsb of the xor&#039;ed byte. If its a 1, we send a key on if the lsb of the read byte is a 1, and a key off if the lsb of the read byte is a 0. We then shift right and do that again. We do that 8 times, once for each bit in that byte. Then we can move on to the next valid address for that channel, write out the address, read back the buffer value, xor, store, analyze, etc. Note, we can speed this up by checking if the xor byte is identically 0x00, in which case we don&#039;t have to analyze it, it hasn&#039;t changed. This will be the usual case! Only occasionally (in sample time), will things change, and usually only on one bit, and thus one buffer, amongst all the channels and buffers. This should help us keep up to speed.<br /> <br /> Once we are done reading all the channel board buffers, we can check the expression pedals and other variable controls for new values, and possibly send control change events. After all this, we actually send the MIDI bytes as we have determined them to need to be for this time around, and go to sleep until our next sample time.<br /> <br /> Not sure what the latency of the serial to USB conversion is in FTDI, but it could be as bad as a single byte in a single USB message.... Anyway, we want to build a buffer of bytes that need to get send over each sample time, with the RTP-MIDI spec used to make it a stream type thing. This means: packet length, &quot;timestamp&quot;, first MIDI event, relative timestamps (should all be zero), subsequent MIDI events.</div>

Admin http://sessrumnir.net/fernseher/index.php?title=MIDI_and_the_organ_project&diff=2121 2009-02-23T04:53:23Z

<p>Admin: </p> <hr /> <div>MIDI standard is out there. Also good is the RTP-MIDI RFC, for putting MIDI data into a stream and whatnot.<br /> <br /> The basics, as I think we will be using them:<br /> <br /> Packet basics (we&#039;ll only be using 3 byte packet forms):<br /> <br /> 1 &lt;3: opcode&gt; &lt;4: channel&gt; 0 &lt;7: arg1&gt; 0 &lt;7: arg2&gt;<br /> <br /> Essentially, a status byte, with the high bit on (0x80-0xFF), and two argument bytes, with the high bit off (0x00-0x7F).<br /> <br /> opcodes of relevance:<br /> *0x0: key off. arg1 is the key number, arg2 is the velocity. We will always use velocity of 0x40.<br /> *0x1: key on. arg1 is the key number, arg2 is the velocity. We will always use the velocity of 0x40.<br /> *0x3: control change. arg1 is the control number (0x01 is modulation wheel, 0x0B is the expression pedal), arg2 is the new control value, from 0x00 - 0x7F<br /> <br /> For channels, we will use:<br /> *0x0: Great (Solo) Manual<br /> *0x1: Swell (Accompaniment) Manual<br /> *0x2: Choir (below Great) Manual, if present<br /> *0x3: Solo (above Swell) Manual, if present<br /> *0x4: Echo (above Solo) Manual, if present<br /> *0x5: Third Pedalboard, if present, or the auxilary stop channel, covering additional stops for all manuals and pedals.<br /> *0x6: Second Pedalboard, if present, or the main stop channel, covering all stops for all manuals and pedals.<br /> *0x7: Main Pedalboard<br /> *0x8: Great stops only<br /> *0x9: Swell stops only<br /> *0xA: Choir stops only<br /> *0xB: Solo stops only<br /> *0xC: Echo stops only<br /> *0xD: Third Pedalboard stops only<br /> *0xE: Second Pedalboard stops only<br /> *0xF: Main Pedalboard stops only<br /> <br /> Our initial organ will only use channels 0x0-0x1, 0x6-0x7.<br /> <br /> Each keyboard channel (0x0-0x7) gets its own control set. For our organ, where the modulation wheel and expression pedal control all divisions equally, each control change gets sent for each active channel... or maybe just for great, and the software will figure out that they control all the stuff. Note, we may not hook up the modulation wheel when we begin. It&#039;d be kinda a lot harder to make work right, I think.<br /> <br /> We will be building channel combination boards, that take an enable and a sub-channel address, and read back the contents of the addressed buffer. 4 bits of address gets 16 buffers. At 8 bits per buffer, thats 128 inputs for each channel. That matches with midi&#039;s numbering scheme. Alternatively, if you take the LSB of the true channel, and feed it to the 4th address bit of the channel board, and only decode the top 3 bits of the channel to determine channel board enable, you can duplex your channel boards, since we will only be using under 64 inputs per channel. The AVR firmware will have an MIDI offset value for each channel to add to the number received from the board before sending as part of a MIDI command. For most subchannels, this will be 36. Will probably just use an offset of 0 for the stop channels.<br /> <br /> Using the split channel board design, we only need two channel boards for our organ. The main board will be designed to use the channel boards in split mode, and will never probably use the split-mode stop channels (0x8-0xF), so it will only have 4 plugs for channel boards, 0x0-0x1, 0x2-0x3, 0x4-0x5, and 0x6-0x7. The initial organ will only use the first and last of these plugs, so we don&#039;t even need to populate the board positions for the other channel boards.<br /> <br /> Also, I think we might want to put all the switch pull-up resistors on the manuals themselves, soldered to the key tabs. This will eliminate a lot of crap on the boards, and keep the board design uniform, since the different keys will need different pull-ups. The manuals, with their 5k internal resistance, will need 50k (or so) pull-ups to 5V, and the pedals and stops, with no internal resistance, will need just 10k (or so) pull-ups to 5V. Each manual will get a separate power and ground plug for the pull-ups and grounds, so the connectors for the keys don&#039;t need a pin for ground or power, I don&#039;t think... Though if there is room, I guess we could send it along there, too. Can&#039;t hurt anything, provided the wires support enough current for the crazy case of all the stop pulled or keys pressed or something. Given a max of 64 inputs to a half-channel, and only 61 keys on a full manual, we can use 2x36 pin connectors for the manuals, and 1x36 pin connector for the pedalboards, and 1x36 pin connector for the stop boards. Thats 6 total 36 pin connectors, male and female, solder cup and through-hole.<br /> <br /> Channel board to main board connectors will have an 8-bit data bus, 4-bit address bus, a power, ground, enable, and identify(?) pins (16 total). Should be able to use IDC connectors and ribbon cable here.</div>

Admin http://sessrumnir.net/fernseher/index.php?title=MIDI_and_the_organ_project&diff=2120 2009-02-23T04:52:12Z

<p>Admin: </p> <hr /> <div>MIDI standard is out there. Also good is the RTP-MIDI RFC, for putting MIDI data into a stream and whatnot.<br /> <br /> The basics, as I think we will be using them:<br /> <br /> Packet basics:<br /> <br /> 1 &lt;3: opcode&gt; &lt;4: channel&gt; 0 &lt;7: arg1&gt; 0 &lt;7: arg2&gt;<br /> <br /> opcodes of relevance:<br /> *0x0: key off. arg1 is the key number, arg2 is the velocity. We will always use velocity of 0x40.<br /> *0x1: key on. arg1 is the key number, arg2 is the velocity. We will always use the velocity of 0x40.<br /> *0x3: control change. arg1 is the control number (0x01 is modulation wheel, 0x0B is the expression pedal), arg2 is the new control value, from 0x00 - 0x7F<br /> <br /> For channels, we will use:<br /> *0x0: Great (Solo) Manual<br /> *0x1: Swell (Accompaniment) Manual<br /> *0x2: Choir (below Great) Manual, if present<br /> *0x3: Solo (above Swell) Manual, if present<br /> *0x4: Echo (above Solo) Manual, if present<br /> *0x5: Third Pedalboard, if present, or the auxilary stop channel, covering additional stops for all manuals and pedals.<br /> *0x6: Second Pedalboard, if present, or the main stop channel, covering all stops for all manuals and pedals.<br /> *0x7: Main Pedalboard<br /> *0x8: Great stops only<br /> *0x9: Swell stops only<br /> *0xA: Choir stops only<br /> *0xB: Solo stops only<br /> *0xC: Echo stops only<br /> *0xD: Third Pedalboard stops only<br /> *0xE: Second Pedalboard stops only<br /> *0xF: Main Pedalboard stops only<br /> <br /> Our initial organ will only use channels 0x0-0x1, 0x6-0x7.<br /> <br /> Each keyboard channel (0x0-0x7) gets its own control set. For our organ, where the modulation wheel and expression pedal control all divisions equally, each control change gets sent for each active channel... or maybe just for great, and the software will figure out that they control all the stuff. Note, we may not hook up the modulation wheel when we begin. It&#039;d be kinda a lot harder to make work right, I think.<br /> <br /> We will be building channel combination boards, that take an enable and a sub-channel address, and read back the contents of the addressed buffer. 4 bits of address gets 16 buffers. At 8 bits per buffer, thats 128 inputs for each channel. That matches with midi&#039;s numbering scheme. Alternatively, if you take the LSB of the true channel, and feed it to the 4th address bit of the channel board, and only decode the top 3 bits of the channel to determine channel board enable, you can duplex your channel boards, since we will only be using under 64 inputs per channel. The AVR firmware will have an MIDI offset value for each channel to add to the number received from the board before sending as part of a MIDI command. For most subchannels, this will be 36. Will probably just use an offset of 0 for the stop channels.<br /> <br /> Using the split channel board design, we only need two channel boards for our organ. The main board will be designed to use the channel boards in split mode, and will never probably use the split-mode stop channels (0x8-0xF), so it will only have 4 plugs for channel boards, 0x0-0x1, 0x2-0x3, 0x4-0x5, and 0x6-0x7. The initial organ will only use the first and last of these plugs, so we don&#039;t even need to populate the board positions for the other channel boards.<br /> <br /> Also, I think we might want to put all the switch pull-up resistors on the manuals themselves, soldered to the key tabs. This will eliminate a lot of crap on the boards, and keep the board design uniform, since the different keys will need different pull-ups. The manuals, with their 5k internal resistance, will need 50k (or so) pull-ups to 5V, and the pedals and stops, with no internal resistance, will need just 10k (or so) pull-ups to 5V. Each manual will get a separate power and ground plug for the pull-ups and grounds, so the connectors for the keys don&#039;t need a pin for ground or power, I don&#039;t think... Though if there is room, I guess we could send it along there, too. Can&#039;t hurt anything, provided the wires support enough current for the crazy case of all the stop pulled or keys pressed or something. Given a max of 64 inputs to a half-channel, and only 61 keys on a full manual, we can use 2x36 pin connectors for the manuals, and 1x36 pin connector for the pedalboards, and 1x36 pin connector for the stop boards. Thats 6 total 36 pin connectors, male and female, solder cup and through-hole.<br /> <br /> Channel board to main board connectors will have an 8-bit data bus, 4-bit address bus, a power, ground, enable, and identify(?) pins (16 total). Should be able to use IDC connectors and ribbon cable here.</div>

Admin http://sessrumnir.net/fernseher/index.php?title=MIDI_and_the_organ_project&diff=2119 2009-02-23T04:25:40Z

<p>Admin: New page: MIDI standard is out there. Also good is the RTP-MIDI RFC, for putting MIDI data into a stream and whatnot. The basics, as I think we will be using them: Packet basics: 1 &lt;3: opcode&gt; &lt;...</p> <hr /> <div>MIDI standard is out there. Also good is the RTP-MIDI RFC, for putting MIDI data into a stream and whatnot.<br /> <br /> The basics, as I think we will be using them:<br /> <br /> Packet basics:<br /> <br /> 1 &lt;3: opcode&gt; &lt;4: channel&gt; 0 &lt;7: arg1&gt; 0 &lt;7: arg2&gt;<br /> <br /> opcodes of relevance:<br /> *0x0: key off. arg1 is the key number, arg2 is the velocity. We will always use velocity of 0x40.<br /> *0x1: key on. arg1 is the key number, arg2 is the velocity. We will always use the velocity of 0x40.<br /> *0x3: control change. arg1 is the control number (0x01 is modulation wheel, 0x0B is the expression pedal), arg2 is the new control value, from 0x00 - 0x7F<br /> <br /> For channels, we will use:<br /> *0x0: Great (Solo) Manual<br /> *0x1: Swell (Accompaniment) Manual<br /> *0x2: Choir (below Great) Manual<br /> *0x3: Solo (above Swell) Manual<br /> *0x4: Echo (above Solo) Manual<br /> *0x5: Pedalboard<br /> *0x6: Second Pedalboard, if any<br /> *0x7: Third Pedalboard. Right.<br /> *0x8: Stop channel. If divided, stops for Great<br /> *0x9: Stop channel for Swell.<br /> *0xA: Stop channel for Choir.<br /> *0xB: Stop channel for Solo.<br /> *0xC: Stop channel for Echo.<br /> *0xD: Stop channel for Pedalboard.<br /> *0xE: Stop channel for Second Pedalboard.<br /> *0xF: Stop channel for Third Pedalboard.<br /> <br /> Each keyboard channel (0x0-0x7) gets its own control set. For our organ, where the modulation wheel and expression pedal control all divisions equally, each control change gets sent for each active channel... or maybe just for great, and the software will figure out that they control all the stuff. Note, we may not hook up the modulation wheel when we begin. It&#039;d be kinda a lot harder to make work right, I think.</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Fernseher&diff=2118 2009-02-23T04:09:27Z

<p>Admin: /* Other Related Projects */</p> <hr /> <div>Fernseher is an all encompassing set of scripts to solve all the world&#039;s problems, determine whether P really does equal NP, make me lots of money, and make a fool of myself, all at once. I imagine it will be useful to no one, do exactly what no one wants it to do, and be accused of murder and money laundering multiple times. If it does what you want it to do, reconsider, because you are probably wrong. It won&#039;t even do what I want it to do, and I wrote the damn thing.<br /> <br /> In summation, your probably don&#039;t really want this set of crap on your box, and if you put it on your box, it is likely that your computer will implode, and almost certain that all your base will belong to me.<br /> <br /> That said, I am using this wiki to keep track of ideas I have for the various components involved, what they do, what they should do, how to use them, how to improve them, and what will happen if you don&#039;t use them with everything else. I am also hoping to do some rudimentary interface design here for the various front ends, as well as backend database design so I know how its all supposed to go together. I may also put any information I have on the various utilities I plan on using to interface with the tuner cards, as well as interfaces to play music and video, adjust channels, volume, use bittorrent, etc. <br /> <br /> ----<br /> ===Backend/Server Components===<br /> <br /> *[[durchcoderd]]<br /> *[[herrd]]<br /> *[[rissd]]<br /> *[[seherd]]<br /> *[[unterhalterd]]<br /> <br /> ===Frontend/Client Components===<br /> <br /> *[[nackt]]<br /> *[[spieler]]<br /> *[[wunscher]]<br /> <br /> ===Database Design and Synchronization===<br /> <br /> *[[Tables]]<br /> *[[Managed Objects]]<br /> *[[Queues]]<br /> *[[Synchronization]]<br /> *[[Clients]]<br /> <br /> ===Components to Harness===<br /> <br /> *[[libgpod]]<br /> *[[vlc]]<br /> *[[mplayer]]<br /> *[[mpg123]]<br /> *[[mencoder]]<br /> *[[curses]]<br /> *[[ajax]]<br /> *[[firefox]]<br /> *[[wiimote mouse]]<br /> *[[tvshows from online]]<br /> <br /> ===Other Related Projects===<br /> <br /> *[[bittorrent]]<br /> *[[blogging queue]]<br /> *[[mpr stream capture]]<br /> *[[photo management]]<br /> *[[email grabber]]<br /> *[[tag clouds]]<br /> *[[remote control device]]<br /> *[[dialup server system]]<br /> *[[distributed internal network]]<br /> *[[dvdlookup.org]]<br /> *[[playlist]]<br /> *[[slackpkg plus plus]]<br /> *[[gkrellm replacement]]<br /> *[[book cataloging]]<br /> *[[some avr stuff]]<br /> *[[modjs]]<br /> *[[thoughs on avr event scheduling]]<br /> *[[MIDI and the organ project]]<br /> ----<br /> <br /> ===Stuff to get working on my computers===<br /> *[[xvmc]]<br /> *[[nis]]<br /> *[[proper dhcp]]<br /> *[[special fw on router]]</div>

Admin http://sessrumnir.net/fernseher/index.php?title=Xvmc&diff=2117 2009-02-15T05:28:05Z

<p>Admin: New page: Stuff that&#039;s needed, according to some website somewhere: *xorg-x11-server-Xorg 1.3.0.0-6 *xorg-x11-server-sdk 1.3.0.0-6 *libXvMC-devel *mesa-libGL-devel 6.5-9 *libdrm-devel 2.0-1 *libXvMC...</p> <hr /> <div>Stuff that&#039;s needed, according to some website somewhere:<br /> *xorg-x11-server-Xorg 1.3.0.0-6<br /> *xorg-x11-server-sdk 1.3.0.0-6<br /> *libXvMC-devel<br /> *mesa-libGL-devel 6.5-9<br /> *libdrm-devel 2.0-1<br /> *libXvMCW<br /> *xf86-video-interl 2.3.0<br /> *xorg-x11-proto-devel 7.3-12<br /> *xorg-server-devel</div>

Admin