<terpstra>
lekernel, "Normally, the entries in the x86 TLBs are not associated with any address space. Hence, every time there is a change in address space, such as a context switch, the entire TLB has to be flushed." -- even intel flushes the entire TLB on context switch!
<lekernel>
intel is no good example... the x86 architecture is slow, bloated and carries a staggering amount of cruft
<lekernel>
who needs instructions for BCD arithmetic for example...
<azonenberg>
lol
<azonenberg>
And that's why the softcore i'm writing is mips
<lekernel>
but yeah, what else to do on a context switch with the TLB except rewrite all of it?
<wolfspraul>
azonenberg: from a freedom perspective, mips is a really bad choice. MIPS Inc. has made it clear many times, publicly, privately - they consider anything MIPS their territory and will defend it vigorously.
<wolfspraul>
just for the record, and completeness. I'm not trying to discourage you.
<wolfspraul>
and that's also just from a freedom perspective and 'we want to be left in peace', not from a technical perspective.
<lekernel>
wolfspraul: btw you should check out azonenberg's work, it's awesome
<wolfspraul>
all the more reason for him to stay clear of mips :-) reading...
<wolfspraul>
I've read mips several times here in recent days, so I thought I bring in some of my experience. If you do anything mips without an architecture license, you are asking for trouble.
<wolfspraul>
I will mention it in my upcoming 05/01 community news, give some people something to read :-)
<aw>
xiangfu, have u built ethernet MAC successfully?
<xiangfu>
aw: what you mean? you mean write MAC address to BIOS?
<aw>
yes. :-)
<xiangfu>
aw: yes. I can build that
<aw>
xiangfu, great, teach me later. :-)
<juliusb>
wolfspraul: what about those longsoon processors?
<juliusb>
as far as I know they've paid MIPS not a cent, and it's kind of open season now with MIPS due to some patent on a particular set of instructions having expired
<juliusb>
ah, i'm wrong - it looks like they caved and paid for a license in 2009
<juliusb>
pussies
<juliusb>
but that processor is particularly interesting as it contains some fancy x86 emulation stuff
<juliusb>
and I think they did some work with QEMU so you could run x86 pretty quickly on the chips
<juliusb>
quite clever
<wolfspraul>
they pay, I can google the press release if you like
<wolfspraul>
bbiab
<wolfspraul>
everybody pays. mips will vigorously defend what they think is theirs.
<wolfspraul>
everybody who wants to know can now, so it's up to everyone to decide.
<wolfspraul>
just email them and ask :-)
<juliusb>
what a joke - OR1K is basicalyl MIPS-I
<juliusb>
you extend OR1K and add the fancy things you want, you have MIPS basically
<juliusb>
why are they so protective over 25 year old crap
<juliusb>
it's not like we're stealing their silicon
<lekernel>
well, no offense, but I do not think that OR1K is really used in the industry
<lekernel>
that might explain partly the absence of trouble from MIPS you've had
<juliusb>
none taken, but we wouldn't have any trouble from MIPS, though - it's similar but different enough
<juliusb>
if we were binary compatible you'd be in trouble but it's not
<juliusb>
anyway, it's just a thought - it's strange they protect their crap so much when it's really nothing special
<lekernel>
strange? well, they want to make money :)
<lekernel>
at opencores too there are 'strange' things which are motivated by the desire to make money. that login wall for example. *grin*
<juliusb>
sure, but why flog a dead horse of some old architecture, make money off good implementations or something
<juliusb>
I guess they're in ARM's game now - selling licenses, except ARM sell good RTL, too
<terpstra>
lekernel, you could keep tags in the TLB just like in L1 cache -- then you wouldn't need to flush it
<terpstra>
so if you had two very tightly cooperating processes passing data via a FIFO (and thus the kernel) you could rapidly switch from P1, kernel, P2, kernel, ...
<terpstra>
and not need to reload the TLB at all
<juliusb>
lekernel: right now they don't even make enough from the site to cover the running costs, somehow
<juliusb>
my argument is removing the login wall would make it more popular
<terpstra>
from what I've been reading, a fully associative tagged TLB would pretty much remove the penalty of reloading it from software.
<terpstra>
but that costs area :-/
<wolfspraul>
juliusb: do you have in writing that MIPS sees no IP overlap with OR1K?
<wolfspraul>
basically first of all you need to stay away from their trademarks, let's start with 'MIPS'
<wolfspraul>
the plasma guys found this out the hard way
<wolfspraul>
if you've done that, you have to be careful about the PDFs you are reading. pretty much all recent MIPS PDFs come with very explicit terms, 'strictly confidential', etc. etc.
<wolfspraul>
if you accidentially copy something from such a document, or draft some design after what you've read there - not good
<wolfspraul>
then you have the patent issue, and the problem here is that MIPS will vigorously protect their 'ecosystem'. So this is not just "patents on our old instructions are all expired".
<wolfspraul>
you can try that, let's just say this way - the Chinese government (!) tried this, and after years of struggling gave up.
<wolfspraul>
do you seriously believe you have more power, financial backing, anything, than the Chinese government? :-)
<wolfspraul>
also MIPS keeps filing for patents all the time, so even if you manage to implement something that can stand their legal tests (lawsuits against you) - you are still stuck in the past, because all paths forward will be patent-mined by MIPS.
<wolfspraul>
bottom line - not a good idea _from a freedom perspective_ (and only that)
<terpstra>
wow. now i hate mips.
<wolfspraul>
no need to hate them more than ARM, Intel, anybody else in semiconductor. They are all IP shops and vigorously defend their IP.
<wolfspraul>
MIPS is quite open and honest, I have no problem with them.
<wolfspraul>
it's more that some people hold this stubborn belief that MIPS is 'open' :-)
<terpstra>
hmm
<wolfspraul>
I have looked into this quite deeply for a while, my last updates were about a year ago or so. It was all clear then. MIPS Inc. can change course, but I doubt it. So that's my disclaimer. "Wolfie's news haven't been updated since mid-2010"
<wolfspraul>
I met with a very senior MIPS officer over this, I have first-hand relationships with Chinese MIPS licensees.
<wolfspraul>
and from the distance (as a news reader) I've seen plasma etc. and what was published there (which is sometimes not the whole story, but anyway I can just read...)
<wolfspraul>
so I was happy to see that Sebastien chose a Mico32 core for Milkymist :-)
<wolfspraul>
oh I'm just googling and read that the Chinese govt plans to buy a 20% stake in MIPS Inc.
<wolfspraul>
let's hope that the 20% thing will not go through
<terpstra>
oh?
<wolfspraul>
worst case MIPS had to make that concession already when ICT (Chinese govt) accepted the architecture license.
<wolfspraul>
those deals are dirty :-)
<wolfspraul>
and everybody just wants power and money, surprisingly :-)
<wolfspraul>
stay away from MIPS, that's all I can say
<wolfspraul>
if you care about freedom
<juliusb>
wolfspraul: very interesting, thanks for the comments
<juliusb>
there's some MIPS clones on OpenCores
<juliusb>
we've heard nothing about it
<wolfspraul>
MIPS tries to make money, not stir up emotions.
<wolfspraul>
the plasma project renamed everything to 'plasma', which is good
<wolfspraul>
plasma is on opencores, no?
<wolfspraul>
what examples of commercial use of non-officially licensed MIPS implementations are you aware of?
<wolfspraul>
also keep in mind - for a business signing that license may not be something that bad, after all
<wolfspraul>
it's just 5-10 cents per chip
<wolfspraul>
unless a business the intention of competing with MIPS, why would they opposed to paying this?
<wolfspraul>
they will focus on their customers, value generation, etc. not on endless fights over 10 cents that everybody else is paying as well.
<wolfspraul>
MIPS will probably not approach you unless your sales reach 10 million units or so, it's not worth the effort for them to contact you before that :-)
<wolfspraul>
also, let me say something in defense of MIPS. MIPS is not a patent troll.
<wolfspraul>
they are a serious IP-based fabless semiconductor company
<wolfspraul>
they will offer everybody very reasonable rates for licensing their technology, and they have different license levels
<wolfspraul>
I think it's a very professionally run, legit and honest company. Like ARM from the distance (I don't know much about ARM, much less than I know about MISP).
<wolfspraul>
MIPS just wants to be as successful as ARM, that's all :-)
<wolfspraul>
fair enough, I think. They are _NOT_ a patent troll.
<wolfspraul>
they do hard work and continuously improve their stuff, which you will get access to if you sign their licenses.
<juliusb>
Sure, I admit that probably both ARM and MIPS won't contact you until you're selling things in volume without a license
<lekernel>
as a matter of fact, ARM did that with nnARM ...
<juliusb>
I wonder, as well, if there's a case of people being hunted down who are suspected of having a particular ISA supported but not having a license
<lekernel>
even though it was just a student project of mediocre quality
<juliusb>
... but not selling their chips to others, I mean - jus thaving it in a product, but making use of the software for the platform, say for ARM
<juliusb>
the BlackARM too, was the one done here in Sweden that earned a request from ARM to be removed
<juliusb>
but that was years ago
<wolfspraul>
there are some companies in Taiwan that claim to have clean-room ARM implementations, forgot the names. faraday or so? I'm not sure how the story continued, just heard it once years ago.
<wolfspraul>
but whatever contracts exist between ARM and Faraday, I guarantee you 100% neither side will say 1 word :-)
<wolfspraul>
why should they...
<wolfspraul>
we could theoretically talk to companies like Faraday about Milkymist. See how scared they are about copyleft, and if not, whether they think there are any business opportunities somewhere.
<wolfspraul>
even if in the end we only learn that there is no way they will use it, it's probably worth the try - not now, maybe a little later
<lekernel>
juliusb: your SoC on http://opencores.org/donation features a DDR2 controller. what ASIC cells do you plan to use for the DDR2 I/Os ?
<lekernel>
those are rather difficult to make afaik
<juliusb>
i know nothing of this
<juliusb>
to me it's not clear how set in stone this ASIC is
<juliusb>
I'm a bit critical of this whole thing, and i'm not involved in it internally here at ORSoC for now, so can't really answer questions
<juliusb>
i have as many as you probably
<juliusb>
if it goes ahead, which i'm a bit skeptical about, it depends largely on how much money they get
<juliusb>
and what they can afford
<lekernel>
to me it depends more on technical skills than money... medium/small ASICs in 350nm in China are only in the tens of thousand dollars
<wolfspraul>
that donation page sounds scary to me :-)
<lekernel>
and given how the vast majority of the Opencores IP that I have tried in my FPGA have technically failed miserably (which is the reason Milkymist uses none btw), I'm quite skeptical how this ASIC would ever happen
<wolfspraul>
"the world's only "true" open-source 32-bit RISC processor supporting Linux (the OpenRISC processor from OpenCores.org)"
<wolfspraul>
is this true?
<lekernel>
no, there's LEON3
<lekernel>
which is GPL and has a MMU, which cuts all LM32 related discussions :)
<lekernel>
and more recently OpenSPARC
<wolfspraul>
yeah
<wolfspraul>
"profit-hunting semiconductor giants who only provide "cost efficient prices" to large multi-national companies"
<wolfspraul>
argh
<wolfspraul>
let's see what that thing costs when it's all said and done, if ever :-)
<wolfspraul>
I think such chips have to enable new applications, or faster time to market.
<wolfspraul>
there's not 1 word about that kind of reasoning on the whole page
<wolfspraul>
just donate and revolution :-)
<juliusb>
ya, I think the whole "only true open source" CPU isn't accurate
<wolfspraul>
juliusb: ok if you can feed this back, here's my worthless wisdom on this
<wolfspraul>
in hardware, you convert money to something physical, right? in manufacturing...
<wolfspraul>
now, how do you convert it back to money? very hard. have to sell fast!
<wolfspraul>
so you need customers first
<wolfspraul>
very important
<wolfspraul>
that's the one thing the nvidia founder and ceo has said over the years, "sell first, then make"
<wolfspraul>
so... for your asic plans. you first need a customer, who puts in a large enough order, with some down-payment.
<wolfspraul>
I doubt you will find a customer because you say your chip is a 'revolution'.
<wolfspraul>
if you cannot, you can try with a) "this chip enables an application that you cannot otherwise implement easily, or at all"
<wolfspraul>
b) "our process is so fast that you can have this hyped feature XYZ everybody is talking about right now on the market 3 months before others"
<wolfspraul>
those 2 arguments are known to work well. I doubt you can do something like "this is the highest overall performance chip in the world", or "whole smartphone on one chip"
<wolfspraul>
so you focus on application, and/or time-to-market
<wolfspraul>
then get an order
<wolfspraul>
then asic
<wolfspraul>
:-)
<wolfspraul>
there is no revolution at all in making a random asic that will then not sell
<juliusb>
I agree
<juliusb>
there's no numbers been presented yet
<wolfspraul>
it's just a pile of silicon you can stock somewhere. at least the boxes are not very big.
<wolfspraul>
well the whole page doesn't look like a good start, to be honest
<roh>
350nm asic? muah...
<roh>
the 80s are back
<wolfspraul>
roh: many many chips are still made in 300nm, 500nm, 1um, etc.
<lekernel>
roh: you'd be surprised how many chips are still manufactured to day in that tech
<wolfspraul>
it's all about economics, in manufacturing
<wolfspraul>
absolutely [lekernel]
<roh>
wolfspraul: really? not only low-clocked stuff?
<lekernel>
afaik 350nm is some 2-5 times faster than the crappy spartan6 we use in this project
<roh>
i mean.. how high can clock go with that? 100mhz?
<roh>
lekernel: it does? wow..
<lekernel>
depends what you do, like with FPGAs...
<wolfspraul>
I don't want to make up applications now, but I do know for sure that 350nm 500nm are very common processes.
<wolfspraul>
manufacturing is about economics, nothing else
<roh>
wolfspraul: sure.
<wolfspraul>
so if someone can be made on written-off equipment, it's very hard to compete with that
<wolfspraul>
you need a good reason to move to a higher process node, because you have to make the 'moving up' costs back
<roh>
wolfspraul: hrhr... you will love the new space here.
<roh>
wolfspraul: if there would be enough money to get some used equipment.. there would be enough space in this building to set up a entire factory for stuff.
<wolfspraul>
yeah I need to speedup coming there, and not be bankrupt before I do :-)
<roh>
;)
<wolfspraul>
roh: did you see the azonenberg paper posted earlier?
<roh>
nope... i dont get to much besides working on the infrastructure here and sleeping atm
<roh>
wolfspraul: nice one
<wolfspraul>
I've seen this chart once from the Ilitek guys making drive-ics for smartphone (and other mobile) lcms
<wolfspraul>
that's one hell of a competitive IC market, with volumes in the hundreds of million of units
<wolfspraul>
so the prices even go to fractions of a US cent :-)
<wolfspraul>
they are constantly trying to reduce die size, and they will do a tape-out whenever they have reached about a 20% reduction in die size
<wolfspraul>
because the cost of going to a new layout and/or process can be made back from the 20% lesser space, over time
<wolfspraul>
with increased volume, the percentage changes (i.e. with higher volume, even a lower saved percentage may justify the cutover)
<wolfspraul>
I've heard about and talked about die size many times more than about process technology (how many nm)
<wolfspraul>
in very high volumes (hundreds of million), I guess die size is the stronger indicator for cost than which process you manufacture in, so that's the one first being optimized for
<roh>
mmmh.. i am not that impressed by the soc of the last 2-3 years
<roh>
loads of low-end crap. nothing really nice.
<wolfspraul>
_first_, not the only one. of course process is also important, and in digital circuits it seems to be 'relatively' easy to switch between processes
<roh>
e.g. there are shitloads of socs specialized for some usecases like 'digital picture frame'.. but they are completely useless since there is not compiler, no useable documentation, no performance besides decoding jpegs... etc. boring stuff.
<roh>
-t
<wolfspraul>
is the silicon wafer the same whether you manufacture in a 300nm or 45nm process?
<wolfspraul>
roh: yeah, that's why we need to introduce some free software and free IC designs there :-)
<roh>
dunno. i think there were some 'regular' wafer formats.. something like 6cm -> 30cm -> whatever
<wolfspraul>
and I think there is a business opportunity somewhere, if we just manage to kick it alive...
<roh>
with some steps in between
<wolfspraul>
6'' 8'' 12''
<wolfspraul>
I'm just wondering whether it is the exact same wafer, irrespective of process technology.
<wolfspraul>
or whether it's different material for a 45nm process, vs. a 500nm process
<wolfspraul>
probably not
<roh>
i guess there will be different levels of material quality
<wolfspraul>
I'm not sure, and I wouldn't be surprised if it's the same.
<wolfspraul>
if it's the same, that would also explain why many people on the manufacturing side care more about die size than process technology
<roh>
wolfspraul: the die is round and bigger die gives more yield per 'good run'
<wolfspraul>
don't understand
<roh>
also because the ones on the 'sides' obviously are scrap
<roh>
try placing sqares on a round surface ;)
<wolfspraul>
I don't think that scrap around the round edge matters, unless you are producing huge chips
<wolfspraul>
Canon produced one CCD chip sized 10x10cm or so once. or even bigger (trying to find the url)
<wolfspraul>
so normally the chips are much smaller
<lekernel>
larsc: do you have a @uni-hamburg.de email address?
<wolfspraul>
like 5x5mm
<wolfspraul>
the advantage of a larger wafer is just that many worksteps have fixed costs, and with a larger wafer you can divide those costs by more chips that are fitting on the larger wafer
<lekernel>
larsc: if so, could you use it to request http://www.webmproject.org/hardware/ ? maybe they care more about academic institutions than open source projects ...
<wolfspraul>
the downside is that the entire line needs to be equipped with more expensive gear
<wolfspraul>
roh: reading those wikipedia semiconductor pages doesn't give a clue whether the wafer is different depending on process
<wolfspraul>
I wouldn't be surprised if it's not, you get that impression from those articles too.
<roh>
true.
<roh>
i found the table with years and µm scale nice
<wolfspraul>
for a manufacturer, the cost of a chip has to do with die size, more than with process technology
<wolfspraul>
going to a higher process technology has a lot of one-time costs, and then maybe you can work with less fabs. And those fabs may give you access to the later technology only if you share some of their costs in turn, like all their customers who access that process technology.
<wolfspraul>
but in the end that's just a system how to finance the huge one-time costs of moving up
<wolfspraul>
if you leave those out (which you cannot), then a chip will always just cost as much as the square millimeters it needs from the wafer
<wolfspraul>
like a piece of a cake :-)
<wolfspraul>
so those different costs and who shoulders them and at what time are a bit inter-twined with each other, but still pretty clear if you think about it for a while
<kristianpaul>
nice paper azonenberg!
<wolfspraul>
I'm wondering if you look at companies like asml making lithography systems, how many 350nm 500nm or even bigger systems they are still selling today, if at all.
<wolfspraul>
we should talk to an asml sales guy one day :-)
<wolfspraul>
so the 500nm fabs still operating today - are they only operating on old, written-off equipment, or can you buy (cheap?) 500nm production equipment still today?
<juliusb_>
ya what's the go with this, I don't understand netsplits yet
<guyzmo>
lekernel - and where shall I add those ?
<larsc>
lekernel: sure (use my uni email address to request the vp8)
<lekernel>
I don't know. checking
<lekernel>
src/luam.h
<guyzmo>
juliusb_ - on IRC you got the clients (you and me) and the servers; there is two kind of servers the hub nodes and the leaf nodes ; usually the hub nodes are the backbone of the IRC network and the leaf nodes connect to the clients. A net split happen when one server looses connectivity with the other servers from the network
<lekernel>
but pray... as it turns out this file lacks a proper RTEMS configuration section
<lekernel>
grmbl
<guyzmo>
lua.h or luam.c ?
<lekernel>
add this at the end
<lekernel>
#define CONFIGURE_INIT
<lekernel>
#include <rtems/confdefs.h>
<lekernel>
luam.c
<lekernel>
you may need to add other stuff for it to work. my first advice was assuming that the Lua port correctly configured RTEMS but it does not.
<lekernel>
you can have a look at flickernoise/src/main.c for the correct way of configuring RTEMS
<guyzmo>
ok
<lekernel>
note that with the way Flickernoise uses RTEMS the entry point is rtems_task Init(rtems_task_argument argument)
<lekernel>
and not int main()
<lekernel>
but you can simply call main() in Init()
<guyzmo>
don't have access to the h:D twitter account
<guyzmo>
that's john
<kraehe>
*ui* moin - this is a full chan - just joined after talking to guyzmo
<guyzmo>
lekernel - I found kraehe on #lua asking for a few rtfm pointers about files, binary and stuff
<lekernel>
hi kraehe
<guyzmo>
and he got very interested in the milkymist and had many questions I couldn't answer :)
<kraehe>
moin - the first is about the name - is milkymist related to milkytracker (gui of dmxtable does not look milky to me ;-)
<guyzmo>
:)
<kraehe>
and more important, guyzmo told that there is still free space on the fpga
<kraehe>
would this space be big enough for an ADC for multi channel audio recording (e.g. 768khz summed up for 16 audio channels)
<lekernel>
no it's related to milkdrop
<kraehe>
and about size - does it have usb drivers for korg nanno eq - would make a nice usb to midi converter for those toys
<azonenberg>
kraehe: how do you expect to implement an ADC on an fpga?
<lekernel>
the adc driver itself would definitely fit, beyond that it depends what you need to do with the sampled signals
<azonenberg>
oh, you mean an adc driver?
<lekernel>
yeah, I'd guess he means external ADC ...
<kraehe>
external ADC wont fit - e.g. my NI has PCI
<kraehe>
and miniPCI ADCs are even more expensive
<lekernel>
and there will be USB drivers for your korg device only if someone (e.g. you) writes them :-)
<kraehe>
i more thought in terms of embedding the ADC+multiplexer on the fpga itself
<lekernel>
you can't put an ADC in the FPGA fabric. FPGAs are digital components.
<kraehe>
*hm* ok - so this would require some additional HW ;-( i'm not the hw guy - more a softworker
<kraehe>
back to the korg nano's - they appear as normal usb-midi under linux. Does the rtems OS already have an USB-midi driver?
<lekernel>
we don't even have a full USB stack atm
<lekernel>
only support for input devices
<kraehe>
so your usb is only keyboard/mouse currently?
<lekernel>
it is technically possible to support all USB devices, but the USB standard is a toxic waste dump of overengineered protocols so doing so would be extremely painful
<kraehe>
;-(
<lekernel>
yes
<lekernel>
that being said, some masochistic people seem to like USB, and having full support for it would be a valuable contrib
<kraehe>
would be easier with rt/linux i think
<lekernel>
no
<lekernel>
it's the same
<kraehe>
except that someone else already wrote the linux driver
<guyzmo>
ok, think I'm ready for the event :)
<guyzmo>
wrote a few lua functions
<guyzmo>
and it would be really fun if we could control a full stage with the device :)
<lekernel>
that small driver is actually the easy part
<lekernel>
the big problem is the USB stack and OHCI (or OHCI-like) controller
<mumptai>
hi
<lekernel>
there's a USB stack in RTEMS (ported from BSD) which would support a generic OHCI controller though
<lekernel>
but OHCI is a royal pain in the ass
<mumptai>
mhmm, sounds like a challenging thesis topic ;)
<CIA-48>
milkymist: BIOS: disable splash screen and console to prevent unnecessary screen flickering
<CIA-48>
milkymist: The BIOS now disables the video output completely unless one of the following conditions is met:
<CIA-48>
milkymist: * Boot in rescue mode
<CIA-48>
milkymist: * Boot failure
<CIA-48>
milkymist: * Boot aborted by user
<CIA-48>
milkymist: * Power button pressed for more than 1 second (approx.) - http://bit.ly/iQVrG2
<juliusb_>
it's the CIA!!!
<juliusb_>
burn the CIA
<juliusb_>
hehe
<guyzmo>
@lua event
<guyzmo>
and I'm ready :)
<CIA-48>
rtems-milkymist: Sebastien Bourdeauducq master * r8e8c101 / c/src/lib/libbsp/lm32/shared/milkymist_gpio/gpio.c : GPIO: do not use generic GPIO driver for buttons. Will be replaced with a keyboard-like one. - http://bit.ly/loaZnK
<lekernel>
cool, rock the place :)
<lekernel>
how many people are there ?
<guyzmo>
20 including me
<guyzmo>
and a few others that are around (like urs, nico etc...)
<lekernel>
he, ok. say hello :)
<kristianpaul>
guyzmo: nice work !!
<kristianpaul>
please record video for the DMX effects you plan to make :-)
<guyzmo>
hehe
<guyzmo>
for now I've done a weird gradated red->red+green->red+green+blue effect
<guyzmo>
and I implemented a sleep() in seconds
<guyzmo>
that sucks
<lekernel>
well i'm sure there will be lua experts at the workshop to give you some hints to do better effects :)
<guyzmo>
ahah
<guyzmo>
it begins with "why does lua sucks ?" :)
<kristianpaul>
guyzmo: are you conding in the lua console in "real time"?
<guyzmo>
copy/paste
<kristianpaul>
ok
<kristianpaul>
(lua experts at the workshop) yeah
<lekernel>
next step is to copy the flickernoise patch editor to make a little Lua IDE? :-)
<kristianpaul>
*green*
<lekernel>
btw, maybe the whole Flickernoise GUI logic could be written in Lua in a next major rewrite
<lekernel>
I think it's better than C for such things
<kristianpaul>
a mtk lua extension?
<lekernel>
remove the little MTK scripting engine, replace it with Lua, write the rest (behaviour description of the GUI) in Lua as well
<lekernel>
instead of the current mess of C callbacks