ptitjes

I have drawn a cross on all my inkscape widgets (two lines)! The crossing of the two lines is the reference point. Easy and efficient :) As for Eagle i don't know. I'm using PCB and you can make your own footprints and defining their reference point where you want!

Hi all! Did someone succeed with the DXF save of inkscape ? I tried it, it worked a long time and when i opened it with DXFViewer, i had only a few things from the original file. Should i make a unique path of my panel by using Difference and Combine tools ?? I have found a company that could cut and engrave my panel. I still don't know what file format i could give them. Thanks for your help. Cheers, Didier.

Hi Cimo, I am proceeding in the same way as you are. I've made inkscape 1:1 versions of my panel widgets based on the exact measures from their datasheets. For each widget i choose a reference point (for example center of the rotation for encoders). I made symbols and footprints for geda and PCB softwares from the measures of the datasheets too with the same reference point. I also made some spreadsheets to compute the exact position of widgets as my panel is quite big (80cm x 45cm). I hope i'll be able to make PCBs' layouts and front panel fit by making 1:1 raster images of the front panel piece of each PCB and importing them in PCB to realize my layouts. Could you please tell us about your success and problems ? I'm really interested as i do it the same way! Best regards, Didier.

Will look at this too! I'll do that tomorow. Cheers, Didier.

ac: "The boxes are color-coded: Main (blue), Input (green), Output (red), Mixed I/O (orange)" LOL... I find that mix of colors a little bit scary!!! We should modify the css to personalize the colors... Also that is a pity you have to put that many \\s... will download the css when i will have time and see whether the float things can be removed! Good work anyway!! That is yet way better than before...

I think there is little bug on the <box> plugin... It automatically inserts a <p> for the box content. So when you immediately put a list you have a carriage return before the list! (see http://www.midibox.org/dokuwiki/doku.php?id=start)

If you have graphviz installed on your server, DokuWiki Graphviz plugin would be very practical for documentation! Also the tag plugin would be cool to better organize the wiki. Finally another "code" box would be a nice to have (like http://wiki.splitbrain.org/plugin:code or http://wiki.splitbrain.org/plugin:code2) Best regards, Didier.

Yeah surely!! The fact is i've got no core for now to work with. But i'm preparing my order for smash. And maybe, i'll have something setup in a few weeks. For now, i'm thinking about the design of such a system. (and also am digesting the PIC18F4685 data sheet... :)) So we must keep it simple! :) Here is what a general plan that is comming into my head (to reorder): - Design abstract messaging schemes (request/reply, publish/subscribe and broadcast) and identify general rules to bind that to CAN protocol - List core services we would need (i can identify for now by order of occurence: node self-advertisement, node configuration, user action publication, node control) - Identify what messaging scheme we need for what service (for instance broadcast for user action publication) - Write use cases for the different MB applications we would like to use this alternative HLP (for each use case a detailed flow of service uses) - Identify, from all the above, system management services and see for each how we can achieve their implementation (using hardware filters and masks or not, fifo or legacy modes..., using interrupts or regular polls in the main loop) For the implementation part, i would really like, as i did not program in assembler for years, that we start making some C bindings for the common PIC configuration (filters and masks configuration, message transmit, message receive interrupt handlers...), implement the HLP above that and then little by little rewrite some stuff in assembly language as needed to achieve better performance. What are your thoughts about that ? Best regards, Didier.

Yihouuu! :) (Sorry for this useless post but i had a feeling i should encourage and thank you, snykehd, for the time you spend on this!!!)

Hi Thorsten, Great, this is what i thought i would do. I wrote this post to explain my position and get feedback from you. I wanted to know whether there still will have a possibility that we could merge in things i could produce if it proves to be useful. So your answer makes me feel you are ok about that. This is how i understood it. Well, for now, i don't think about OSC or ACN, but in fact i see in CAN a good way to add features around MB that maybe require some other micro-controller. I mean getting the best of MIOS/PIC and plugging something else (like a PC) for more complex tasks. Please don't ever think i'm spitting on your work. I just find what you have done is huge!! Thanks for your feedback. Best regards, Didier.

Hi all, I read stuff about CAN these last days as i want to use it to interconnect my future MB's four cores and my computer. I've also read about MBNet and this raised me a lot thoughts and questions, especially about the MBNet HLP and its request/reply and master/slave design. Disclaimer: By posting this topic, i don't want to offend anyone. I've got lot of respect for the work of the MB community and I am also very thankful for that. I hope those comments and questions don't arrive too late. I'll try to sum that up in the most ordered way i can. Please apologize for the length of the post. Use Case 1: MidiBox Extension thru CAN port (a la CiA) ---------------------------------------------------- I think providing an standard way for extending the midibox via a CAN port would be a very good thing. Lots of people have made extension ports for their midibox, all of which are quite incompatible. A CAN port could make an easy way to connect and extend MidiBoxes, provided that the extension requires itself a new core. If such a thing is made possible with the new PICs, it seems to me that the MBNet HLP request/reply design and master/slave model is quite limited in that respect. For instance for hot-pluging new devices, Masters are forced to poll regularly the network to see if new devices are connected. More over, it has to ping all the devices by their id. Regular discovery protocols uses advertisement messages (new devices on the network advertises themselves at plug time). This design avoid the overhead of having to ping the potentially existing devices addresses. With a CAN port, plug time could be easily detected by the MB extension thanks to the incoming current. But the HLP must permit any node to post advertisement messages. Also why correlate the node id to the PIC ids ? Imagine person X comes at Y's home wants to connect its midibox on Y's one and realize they have the same PIC ids ?? Use Case 2: Different cores with different responsibilities ------------------------------------------------------ In my future midibox, i would like to have three different types of nodes. Node CS1 and CS2: 8 channel strip (with motor-fader and encoders) Node P: Paging (or layering if you prefer) system with paging control buttons and navigation control Node S: Storage of the fader positions for the different pages. User press a "Next page" button on node P, P sends a page change event on the CAN bus. S observes the page change event and accordingly sends the corresponding fader position change events on the CAN bus. CS1 and CS2 observes the fader position change events and react accordingly. (I gave the example of fader positions as I have no LCDs on CS1 and CS2. But i could have wanted to display the track names with some LCDs and send the track names the same way.) I don't see how i can make my protocol fit in the MBNet HLP. Who is master and who is slave ? Use Case 3: DMX Connector Node (or whatever protocol PIC is not able to handle) ------------------------------------------------------------------------------- Let's say we want to extend a midibox with a node that handles another protocol than MIDI, let's say DMX. I want that node to be remote configurable. For instance, i would tell him that fader changes of one other node is to be transformed in changes of the x DMX circuit, and so forth... However, the node that owns the fader do not know that new node. Neither should he know the other node that currently transmits fader changes as MIDI CCs. This uses case shows that if we want extensibility, we need multi-cast if not broadcast capabilities with the MBNet HLP. I would like to propose for an extension of the MBNet HLP to enable such use cases. In fact, I think restricting the protocol to a request/reply and master/slave design really limits the future potential use of the CAN interface. Maybe we could make the existing HLP a subset of a more versatile HLP. I don't know if implementing an existing HLP would be so much work. I'm currently reading the CanKingdom spec and will have a better view of that later. It seems however that CanKingdom is the existing HLP that is the best suited for control. Here are some thoughts of my whishlist for the HLP: - Dynamic allocation of node ids at startup and after hotplugs. - Core communication routines (request/reply, publish/subscribe and broadcast) - Core services (such as discovery protocol, ping protocol, application upgrade, remote control and configuration) - Dynamic allocation of application-specific services' CAN message identifiers Ok, sorry for all that. I hope i didn't bother everyone... Best regards, Didier. (MidiBox rocks!)

Hi! Cool initiative... i was desperating about the way the previous try to bulk order in the deutch forum had turn in!

Ok! no problem. I do it! Edit: Done!

Yes! Maybe you should PM those who were initially interested because if they are available and cap included it is more than interesting! Also maybe you should do a new post in the English forum. I'm waiting to see how many people want to participate to the buy, but anyway i think that if we do just reach something like 100 pieces, i will take the last ones.

Hendrik: I can take the last 48. I proposed this to you so that you can benefit the sale a bit. So if there are people to take the 128 pieces then i can take 72. Maybe that would be better if i endorse the buy. Could you give me all the informations by PM ?

But for the 10.66€ VAT included price, we gathered people to take 152 pieces out of the 200. Have you read seppoman's message? He's right! Those 48 last could be sold on eBay for a very good price. If we go for the 200 pieces buy, I can take 24 more to re-sell them after. If you take the last 24 more, we agree on the price to sell them on eBay and they will be sold very shortly. It's very logical. Higher the price, fewer the people that wants to buy. Please explain your problem in going for the 200 pieces Abacus.

But why not go for the buy through Abacus ?

TK: I had a LinkSys WAP54g and a friend of mine has made it run openWRT for years now (until it died in fact ;)) and it worked like a charm. However we did not open the box to look at what it's in it. As for ACN and audio manufacturers, i just think that having standard Ethernet you can just handle the protocols you need OSC, ArtNet or ACN in the future. But nevertheless, i have faith that ACN's support by audio manufacturers will grow in the year, pushed by the light ACN-enabled devices. This one should be easier than the entry of AES50 in the market (despite it is better than Ethersound). Your CAN-to-USB and CAN-to-Ethernet bridges suggestion are nice. (I'll dig first in this direction) However, as i already need to embedded a PC-grade computer in my midibox (to handle two touch screens), i was wondering whether it would be possible to connect that PC directly to CAN and avoid yet another controller chip in between. Regards, Didier.

Hello! Very interesting topic! TK: I don't see any way to handle the parameter declaration in a standard way using only OSC. However, and this is the power of the LAN, you could easily imagine a protocol stack to handle that and many more case. Here is what would be the puzzle pieces: - The parameters and capabilities of the device would be expressed with RDF (Resource Description Framework) as a description document. - Discovery of OSC devices on the LAN would be made through ZeroConf/Bonjour or another discovery protocol. However, it seems there is already an upcoming protocol stack for doing all that. It is the future replacement of DMX which is called ACN (Architecture for Control Networks - http://en.wikipedia.org/wiki/Architecture_for_Control_Networks). But it is really lot more effeicient and broad than DMX. It can be used (and will surely) to control audio devices from audio consoles. I've yet seen only 2 spotlights compatible with ACN at the last SIEL but there might be a lot more arriving this year. And also some consoles and software are said to be ACN compatible. The question is how to things like this based on the MBHP. It appears handling all the Ethernet/protocol stack with the PIC is completely imaginary. But i imagine that MBHP core could communicate through CAN with a very little PC board, embedded in the midibox, running linux with an ad hoc driver and software. However i can't figure out how the CAN bus could be connected to the PC. Could give me your views on this ? (Edit) A bit more on ACN. It is divided in three parts: Configuration, Test, and Control : - The Control part is similar to ArtNet and OSC, and is the part of the protocol highly optimized to be used during performance. I think one could an analogy to MIDI's short messages in terms of efficiency. - The Configuration part enables to configure remote equipment. Here you get discovery, parameter descriptions and al. It is only to be used before performance and is as efficient as MIDI sysex. - Finaly the Test part is to enable reporting of device failures. For example a spotlight could report its bulb is dead. I think all this could open lots of new applications for MidiBox! :) Regards, Didier.

Mail sent. Took 24. Cheers. Didier.

Yé! Like your name says... a $$™ chance ;) (Sorry for the troll... but this topic was going nowhere, i could not resist to participate!)

In fact, that is a solution (poor man's solution but a solution). However, the reason I thought about white is that with the light emitted by the two 15" screen it would have been very bright even in dark environment (like theaters which is its main aimed use). But i'll try to see what yellow renders. Any other idea ?

Hi! Hendrik: If the 10€ order would still take place i'm offering to *participate* in paying the remaining 50 pieces so that we can then sell them via eBay or on the forum. Nothing in common with that ^^^^ but again i ask the question: Who is interested in taking RSA0N11M9A07 instead of RSA0N11M9A06 ?? (Sorry if my question is annoying...) Didier.

Hi all, I've designed a front panel. However i'm wondering whether/how i can have white on dark gray... It seems that shaeffer can not print large color blocks. I thought about using printable alluminium sheet. However, i don't figure how to print white as no printer (that I know) has white ink. Could someone give me ideas or tell me how it is possible (or not) ? Here is my design : http://ptitjes.free.fr/mute-hui/design-touchscreens-v2.pdf Thanks for your help all! Regards, Didier.

Custom taxes ? Even inside Europe ? Also what is the VAT in Germany ? Thanks. Didier.