| xiangfu | wpwrak, the DMX device will arrive today evening. good news. :) because I got a message yesterday. it said will delay ~5 days. :) | 08:33 |
|---|---|---|
| xiangfu | then I will upload some pictures | 08:34 |
| xiangfu | maybe I will got them in next 3 or 4 hours. | 08:34 |
| aw_ | xiangfu, http://dpaste.com/666344/ Does it show that 'lm32-rtems4.11' compiles well and boot.bin without err ? | 11:56 |
| wpwrak | looks good, yes | 12:05 |
| wpwrak | aw_: (fedex) thanks !! | 12:06 |
| wpwrak | aw_: what total declared value did you put ? | 12:07 |
| aw_ | wpwrak, great. I've not put declared value yet. Don't tell me now. hehe ... one day let me figured it out. just want to confirm tool is okay. :) | 12:14 |
| wpwrak | no, i mean on the fedex shipment | 12:16 |
| wpwrak | or did you not declare the value of the shipment ? | 12:16 |
| aw_ | ha ~ the fedex declared value I put USD 35 only. :) | 12:17 |
| aw_ | reason: repair since the M1 looks a repair board. :) | 12:18 |
| aw_ | do u think it's okay ? | 12:18 |
| wpwrak | hehe ;-)) | 12:18 |
| wpwrak | let's see what happens | 12:19 |
| wpwrak | i usually try not to give them an excuse to stop it at customs and make me go there. but well, maybe it works. | 12:19 |
| aw_ | i did mostly like that way. so hopefully it goes through | 12:19 |
| aw_ | one question: how can I know mostly that compiler works well in linux environment ? just dig into each Makefile to see what they do ? or other way ? | 12:21 |
| aw_ | in the window IDE environment, I usually see the 'output windows' to see the results of compilation. And smart IDE tool with different color automatically to point err /or warn lines. | 12:24 |
| aw_ | so in terminal, how should I focus on compiling ? | 12:25 |
| aw_ | Are my questions stupid enough ? or don't ask in that way, and just _do_ it ? | 12:27 |
| wpwrak | aw_: if there's an error, it will tell you at the end :) | 12:35 |
| wpwrak | aw_: and soon, the compilations will be less chatty. then it will be MUCH easier to spot problems | 12:35 |
| xiangfu | aw_, ( http://dpaste.com/666344/ ) looks fine. | 12:46 |
| xiangfu | aw_, you can try the boot.bin now. | 12:46 |
| xiangfu | aw_, but there is no image's CRC in this boot.bin | 12:46 |
| aw_ | wpwrak, oah ~ see it now. I just intended to type wrong, compiled and understood your 'less' vs 'MUCH'. thanks ! I.e. all the results are in way of historical context. | 12:46 |
| aw_ | xiangfu, oah ~ yes. Thanks ! I also saw a file 'append_crc_len.sh'. So does it work for it ? | 12:48 |
| xiangfu | aw_, yes. it works fine. it needs one parameter: IMAGES_DIR | 12:53 |
| xiangfu | aw_, this patch should contain all images. | 12:55 |
| aw_ | xiangfu, I don't know them now. he. :) | 13:04 |
| wpwrak | aw_: (less/MUCH) ah, i meant something else: the patches xiangfu just posted will reduce the output during a normal compilation. so if there is any problem, the error message will be easy to spot | 13:06 |
| xiangfu | aw_, s/this patch/this path/ | 13:07 |
| aw_ | xiangfu, wpwrak ha ~ got it. | 13:10 |
| xiangfu | aw_, hmm... I will think about this boot.crc.bin. the release image don't have bios-rescue and splash-rescue. | 13:12 |
| xiangfu | oh. | 13:12 |
| wolfspraul | interesting, reading about Lemur http://en.wikipedia.org/wiki/Lemur_Input_Device | 15:01 |
| wolfspraul | this was a multi-touch osc controller which sold for 1500-2000 USD and used by serious artists and performers for a few years | 15:02 |
| wolfspraul | seems they retreated peacefully from the marketplace after the ipad showed up and killed their business... | 15:02 |
| wolfspraul | http://www.jazzmutant.com/newsletter.php | 15:02 |
| wolfspraul | http://www.jazzmutant.com/ (farewell post) | 15:03 |
| wolfspraul | I am harvesting their remaining reseller links, those are all good leads for Milkymist imho http://www.jazzmutant.com/order.php | 15:03 |
| wolfspraul | I am wondering how many were sold in total, they seem to have an impressive list of artists who used it, so I don't know | 15:06 |
| wolfspraul | I'd say 500 at least | 15:06 |
| lekernel__ | further reason to go beyond the touchscreen...? | 15:06 |
| wolfspraul | 500-2000 ? even more? | 15:06 |
| wolfspraul | well if I think about their product it's clear they had no chance against the ipad | 15:06 |
| wolfspraul | maybe they can port their software over, but then I don't know how attractive it still is to real artists... | 15:07 |
| wolfspraul | anyway, I just foudn out about it, following old leads from guys I met | 15:07 |
| wolfspraul | Lemur :-) | 15:07 |
| wolfspraul | good thing I foudn their reseller list before they are shutting down the entire jazzmutant.com site, seems soon... | 15:07 |
| lekernel__ | what's worrying me (yeah, always pessimistic, I know) is they still got killed despite these resellers and impressive list of artists | 15:08 |
| wolfspraul | how could they not? | 15:08 |
| wolfspraul | some of those artists may not have been paying customers, we don't know | 15:09 |
| wolfspraul | then how many additional customers are really drawn to a 1500-2000 USD product, no matter how many Bjoerks use it? | 15:09 |
| wolfspraul | I think it will be in the hundreds, at the very most low thousands | 15:09 |
| wolfspraul | so let's say 2000 | 15:09 |
| wolfspraul | 2000 * 1000 = 2 million USD | 15:09 |
| wolfspraul | they have to fund everything from that, which is possible but still tough business | 15:09 |
| wolfspraul | several people for several years, marketing, manufacturing, software development, etc. | 15:10 |
| wolfspraul | and then the ipad comes | 15:10 |
| wolfspraul | and booom | 15:10 |
| wolfspraul | they have no chance | 15:10 |
| wolfspraul | I mean that thing even looks like an ipad before the ipad, no? :-) from the pics | 15:12 |
| wolfspraul | they should have sued Apple | 15:12 |
| wolfspraul | unfortunately in the real world they would need at least a 100 million USD investment or so to take on such a 'project' | 15:12 |
| wolfspraul | what do these guys do now? | 15:13 |
| wolfspraul | must be something interesting :-) | 15:13 |
| lekernel__ | http://www.jazzmutant.com/lemur_gallery_videos.php | 15:14 |
| lekernel__ | well, yes... it's an ipad :) | 15:14 |
| lekernel__ | http://www.stantum.com/en/ that's their parent company | 15:20 |
| lekernel__ | http://www.stantum.com/en/solutions/supply | 15:22 |
| wpwrak | (lemur) interesting. so that's where iCon got their idea for their USD 125 controller from :) | 15:56 |
| wpwrak | lekernel__: btw, any comment on my fpvm.c cosmetic changes ? okay to proceed in this direction ? | 16:00 |
| lekernel__ | wpwrak: still need to have a deeper look at it, but the idea was to make libfpvm relatively generic | 16:03 |
| lekernel__ | that's why it works on equations and not patches | 16:03 |
| lekernel__ | that's an attempt to limit spaghetti code and have clearer interfaces :) | 16:04 |
| lekernel__ | do you think the fpvm equation parser could take over within a better/more conventional patch parser (I agree it could be improved) and read characters until some delimiter? (\n, ;, etc.) | 16:06 |
| wpwrak | stacking parsers inside parsers tends to be messy. but where do you need "naked" equations anyway ? the prologue and epilogue could be treated like regular patches as well - and look better than they do today | 16:09 |
| lekernel__ | this is more an attempt to keep some modularity than anything else | 16:11 |
| wpwrak | if you really need "naked" equations, you can steer the grammar towards some special start state | 16:11 |
| lekernel__ | I don't need naked equations... except for prologue/epilogue as you said | 16:12 |
| lekernel__ | it's for keeping it modular | 16:12 |
| wpwrak | naw, just makes things complicated :) the language is pretty simple. breaking things up in the middle adds mainly complexity. worse, you have a lot of information that's shared between both sides (e.g., predefined variables) | 16:13 |
| lekernel__ | libfpvm implements fast equations on the hw accelerator, with a clear interface | 16:13 |
| wpwrak | the most straightforward solution would be to move the whole parser into flickernoise :) | 16:13 |
| lekernel__ | then you can build other stuff on top of this, like the patch parser | 16:13 |
| wpwrak | you could make the AST or something similar the interface. then you don't break up the language | 16:14 |
| lekernel__ | that's a possibility, but then inserting the prologue/epilogue by manipulating the AST in C is messy | 16:15 |
| wpwrak | not at all. you'd just run it through the parser like the patch itself | 16:16 |
| wpwrak | so you build one AST or AST-like thing | 16:16 |
| wpwrak | bascially whatever you have right above dynamic register allocation and code generation makes a "clean" interface | 16:17 |
| lekernel__ | yes, I agree with the AST interface solution | 16:17 |
| wpwrak | below all this, you have another "clean" interface (i.e., one the scheduler uses) | 16:17 |
| lekernel__ | as long as prologue/epilogue aren't messy :) | 16:17 |
| lekernel__ | btw, you can drop the demo firmware if you make large changes like this | 16:18 |
| wpwrak | i would hope to just have them in files :) or some long-string-embedded-in-C equivalent | 16:18 |
| wpwrak | right now, they're kinda hard to decipher anyway | 16:18 |
| lekernel__ | nowhere near as hard as manual allocation of AST nodes :) | 16:19 |
| wpwrak | (demo) excellent, thanks !! i was worried about that one :) | 16:19 |
| wpwrak | you could write the prologue and epilogue in hand-optimized "assembler". then everybody would believe it's for performance ;-)) | 16:20 |
| wpwrak | but i think it'll work just fine to turn this into a "program" that looks like a regular patch | 16:20 |
| lekernel__ | not really, you need to take care of the single-use registers | 16:20 |
| lekernel__ | and assembly wouldn't even be efficient | 16:21 |
| lekernel__ | just run it through some parser like it's done now | 16:21 |
| lekernel__ | that's the best solution | 16:21 |
| wpwrak | funny. the lemur is just how i pictured our touch screen should be. i'd just not use real multi-touch (need some buttons on the side, though) and would use less colors | 16:24 |
| wpwrak | i have a few openmoko touch screens lying around. these would in theory be easy for prototyping. alas, they're tiny | 16:27 |
| wpwrak | i also have one or two P2P clones from HXD8. they're a little bigger. hmm... | 16:28 |
| kristianpaul | wow prety futuristic this lemur, well i guess for its born time | 16:34 |
| wpwrak | that was just 6 years ago | 16:35 |
| kristianpaul | hum | 16:40 |
| GitHub96 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/ec51f09c98676a6b14be3abfdaa43f995a855458 | 16:48 |
| GitHub96 | [migen/master] Case support + register bank generator - Sebastien Bourdeauducq | 16:48 |
| GitHub164 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/4340680704900b8836380012ca6c56dc8c4f5267 | 18:29 |
| GitHub164 | [migen/master] Cleanup - Sebastien Bourdeauducq | 18:29 |
| GitHub38 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/0e8d894a354652c6dd361f31818e8b9e625efc77 | 21:04 |
| GitHub38 | [migen/master] Variable conversion - Sebastien Bourdeauducq | 21:04 |
| wpwrak | pity that we'll probably want to run algorithmic optimizations on the AST later. otherwise, the parser could just generate code directly | 22:46 |
| azonenberg | Hmm | 23:14 |
| azonenberg | The datasheet and timing analysis disagree | 23:14 |
| azonenberg | as to the high end of the BUFG clock range | 23:14 |
| azonenberg | I'm creating a PoC design (just a single LUT and a flipflop configured as a divide-by-two) that I want to clock as fast as I can | 23:14 |
| azonenberg | using a 100 Mhz input clock multiplied up by a PLL_ADV | 23:14 |
| azonenberg | The datasheet seems to suggest the global clock network runs up to 400 Mhz | 23:15 |
| azonenberg | But my design passes timing at a 5x multiplier | 23:15 |
| azonenberg | Any guesses as to which one to believe and how ot test this for sure? | 23:15 |
| wpwrak | are you saying it works beyond the guaranteed specs ? where's the problem then ? | 23:20 |
| wpwrak | hmm, i wonder if variable names like "sin", "cos", etc., are valid in milkdrop. they would currently be in FNP, but that's not necessarily a nice feature. | 23:58 |
| n0carri3r | whoa, big site update :) | 23:58 |
| n0carri3r | thanks for the concert shots! | 23:58 |
| --- Tue Dec 6 2011 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!