Giter Site home page Giter Site logo

jkominek / piano-conversion Goto Github PK

View Code? Open in Web Editor NEW
38.0 38.0 6.0 26.62 MB

Hardware, and some firmware, for acoustic piano to MIDI controller conversion.

License: Other

C 98.45% Assembly 0.40% Makefile 0.31% Python 0.76% OpenSCAD 0.09%
hardware midi-controller piano

piano-conversion's People

Contributors

jkominek avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

piano-conversion's Issues

MIDI board Rev 0

  • Might be able to drop one of the logic buffers, since we've moved the UART right onto the board. Check that. Want to keep the open collector inverter, as it means we don't have to configure the UART to invert bits or anything for us.
  • FInal schematic/footprint/layout check.

Sensor board PCB

I produced a bunch of variations on the sensor board very quickly, to account for the changes in my mechanical plan. Improvements:

  • Fix silk screen and labelling
  • More test points
    • In particular, the nets between each of the LEDs need to be exposed, so that if/when nonconductive coating is applied to the back of the PCB, individual sensors can still be tested.
  • Ground pours on the top and bottom, tied to the mounting holes.
  • Mounting holes stitched with vias.
  • Correct the spacing on the mounting holes. Should be exactly 20mm.
  • Reduce the LED power & analog signal overlap.

Additionally, I'd like to make a variation on some of them that uses the EAITRCA6 from Everlight. It's a similar, but much thinner sensor. Looks like it could be surface mounted, which would allow the sensor PCBs to rest flush against their support. That should eliminate flex when the hammer impacts.

Sensor test board Rev 1

  • Put all of the little 2 pin headers on a uniform 0.100" grid so that they can be held in place by a breadboard while soldering.
  • Consider uniform-izing the regulator part types.
  • Consider having both a 2.0V regulator and a 2.0V precision reference and the ability to swap between them.
  • Indicate which spots need shunts on them, and which don't, for operation. Looks like one "voltage" measurement has to be shunted, and the other doesn't? Confused me and I made it.

LED power rev 3

  • Need a bit more thermal relief on the passives connected to the top layer copper pour. They're sort of a pain to hand solder.
  • C10 (incoming .1uF on the 48V rail) is just a bit too close to J9
  • Why did I use different resistor values for R24 (Vref drain) and R9 (/SHDN pullup)? No reason I couldn't just use some arbitrary value in the 2.2k-5k range for both. Pick something I'm using elsewhere (the dividers?) that actually matters and just use that for both, to reduce BOM.
  • R0 is unnecessary for draining the big cap now that we've got the voltage divider on +48V, draining 0.5W all the time (huh, maybe i should up the total resistance of the voltage divider)
  • Eliminate the need for the +15V supply, by regulating the +48V down to about +24V with an LM317. Should be cheaper than putting the second screw terminal on the board. The op amps can use the +24V directly, and that should be low enough for the 5V regulator feeding the precision voltage reference. Expected current draw on the whole rail is <1mA, as we're just feeding quiescent currents and the op amps are keeping MOSFET gates stable.
  • /IRQ line should be pulled down with a transistor, instead of directly attached to a pin.

ADC Board Rev 3

Place to record necessary changes for rev 3 of the board:

Necessary changes

  • 4.5V regulator, LP2985AIM5-4.5/NOPB ("SOT-23-5")
  • 3.3V regulator, NCP115ASN330T2G ("TSOP-5" which is SOT-23-5)
  • 2.0V precision voltage reference, LM4120IM5-2.0/NOPB ("SOT-23-5")
  • Rearrange the analog voltage distribution. The phototransistors and op amps should be driven by the 4.5V. The 3.3V for STM32 VAA and op amps V+. 2.0V as Vref+.
  • Unify the ground planes, per STM32 EMC doc, and the people who seem to know the most about the subject.
  • Double check that we're keeping all of our decoupling cap traces as short as possible.
  • Tidy up analog area traces.
  • Do anything else I can learn to do to improve EMC before I feel like having these boards built.
  • Adjust USBLC6-2SC6 footprint to also accept MAX3207EAUT.
    • This means shorting some pins together on the PCB. Make the traces for that swing out wide from the part, so they're cuttable when using the USBLC6-2SC6.
    • That'll also mean that you can just leave the part out entirely, which is probably good.

Main board rev 1

Place to record necessary changes for rev 1 of the board:

Important

  • MicroSD card slot.
  • RS485 transceiver SO8 footprint appears to be wrong; awkwardly wide and difficult to solder.
  • Compress the board to <= 100x100mm.
  • Remove all ethernet
  • Expose a couple of carefully chosen GPIO to act as ~IRQ pins for external Qwiic boards. Bring them out on headers, kind of like the switches/LEDs/etc.
  • Change the FET footprints to SOT-23-3 to accomodate JLCPCB SMT basic parts library.
  • Swap USB D+/D- into the correct positions.

Noncritical issue

  • Scoot the +5V and GND silkscreen slightly further away from the power connector.
  • Add silkscreen to put the JLCPCB part number under a stack of RJ45 jacks.
  • The Qwiic headers will be hard to hand solder. Giving them some more space sort of contradicts the plan to narrow the board, but anything we can accomplish will help.
  • Increase the space between the 3.3V regulator, and the power/reset/status header, to ease rework.
  • Bump up the size of the electrolytic cap footprints by 1, to better match the cap selection you get in variety packs.

LED Power board Rev 2

  • Vref net requires a pulldown (2.4k seems to be working fine) in order to drain the charge to 0V when the MCP1501 is shut down by the MCP23017. Without it, Vref basically floats, and the the constant current goes undefined.
  • Voltage dividers on +15V and +48V to turn them into inputs for the IO expander, so it can check that the supplies are working.

Noncritical

  • Increase the space between the Qwiic connectors to ease hand soldering.
  • Bring the I2C bus out to a 0.100" header.
  • Still need more space between the individual string screw terminals/headers and their corresponding indicator LEDs. It should be sufficient to bring them in towards the middle by 0.5mm, which should roughly line them up with the courtyard of the mosfets.

Update PCB layouts with new revision number & generate gerber files

I update the board revision number right before producing gerber files. So this will be the very last thing to do on the milestone.

  • Commit updated silkscreen for all boards

Generate gerber files for the following, and attach to the release:

  • Main board rev1
  • ADC board rev2
  • LED power rev1
  • Sensor test rev1
  • Pedal rev1
  • MIDI rev1

LED Power Rev 1 bringup

  • Make sure the 5V regulator doesn't explode the MCP1501.
  • Check IO expander. Not necessary for a useful board.
  • Check I2C pass through performance?

Pedal Board Rev 2

  • The TRS tips, which goes to the ADC inputs, have a series resistors on them, but we should add some caps to those signals, near the connector. This will help clean up the signal, and add ESD protection. 10 ohm series + 1uF should be a ~15kHz cutoff frequency, which is still higher frequency than necessary, but should help reduce aliasing, and keeps the cap size reasonable.
  • Convert to use of an STM32G0
  • We can add support for IRQ lines, now that there will be a tiny uC to detect changes. Add the header, and insert the transistor necessary to perform the pull downs.
  • Connect every single TRS signal (3 pins, 4 connectors) to a different ADC input on the STM32. By converting some of the pins on every connector to outputs and applying 0s and 1s appropriately, we can supply the power for the potentiometer in the pedal to work. Then the ADC can read the remaining pin per connector, and use that result.
    • more of a firmware issue, but start thinking now, what's the algorithm to automatically determine the pedal's configuration?
  • Bring out at least four of the ADC lines on header pins, along with VCC and GND, to facilitate connections to a broader range of sensors. Possibly all of the ADC lines.

Toy/barebones synthesizer + audio output module

A sort of pie-in-the-sky idea, that isn't part of any milestone, or blocking anything:

A board, conforming to the overall I2C/Qwiic scheme, which presents itself like the I2C UART on the MIDI output board, basically taking a stream of MIDI data written to register 0x00. But instead of streaming that MIDI data elsewhere, it runs it through a simple synth, generating an analog signal, and feeding it to any of line outs, headphone amps, or power amps for real speakers.

I don't have any interest in trying to implement even a sample-based piano synth in hardware, let alone a fancier synth than that. But some simple 32 voice sine wave + some harmonics that responds to note on velocities, note off, and sustain pedal could maybe be useful? I'm imagining a situation where you've taken a unit to a tech for them to work on the regulation of the system after confirming that whatever your issue is, is present even when using this simple synth.

It would also serve as a reference for anyone who wanted to build a more advanced synth. For instance, it is possible to get a Raspberry Pi to act as an I2C slave device. So, you could make a board that brings in the Qwiic connection, has plugs for a Raspberry Pi compute module (both for it to mount, and so you can put a display/keyboard/mouse on it), takes the audio output from the module, runs it through amps. Then you could slap Pianoteq on the Pi module, and have a largely standalone system with "real" synthesis and "real" audio.

MIDI board rev 2

  • Silkscreen labels for the I2C pin header.
  • Reevaluate usage of TLP185(SE, which appears to be globally out of stock.
    • Pretty sure there are some compatible ones. I'll want to double double check the footprint and such, but this item is probably a no-op.
  • Convert to using an STM32G0. (And remove the oscillator)
  • Replace the open-drain buffer with a transistor. (MOSFET is probably inappropriate considering the switching.)
  • Use a transistor to pull down the IRQ lines.

LED Power Rev 1

Most of the fixes necessary for Rev 1 have been made and are covered under the Board Revision Notes.

  • Ferrite beads on the incoming power lines? The +15V and +48V are only used by linear devices, so the only HF noise will come from the supplies. We're not generating anything we should try to trap.
  • Final schematic/footprint/layout check.

Cables

Would using these parts make the ADCboard to sensorboard cables easier to build?

Cable: https://www.digikey.com/en/products/detail/3m/HF100-40TP/3911407
Connector on the ADCboard side: https://www.amazon.com/dp/B00K2NTSJE/
Connector on the sensorboard side: regular jumper to be crimped, such as https://www.digikey.com/en/products/detail/harwin-inc/M20-1160046/3919438

This will cut in half the number of pins that need to be crimped (yay... but see below for even better) produce neatly organized cables (yay), and give some screening protection from noise by virtue of being twisted (yay).

I looked (not very hard) for single-row of stuff like https://www.amazon.com/dp/B0936Q6BDX/ which would eliminate the need of crimping.... or we can use two rows connectors rather than single row on the sensorboard too?

Now of course not everything will fit into the 4x arrangement (I'm planning to leave some of those sensors unconnected), so some cable-fu is still needed, but not as much as if we'd be wiring all 176 sensors (each with two cables, each with two ends) with a regular crimped connector. Am I missing something?

Note that if necessary the HF100-40TP cable can be ordered with custom lengths, as mentioned at https://multimedia.3m.com/mws/media/671953O/3mtm-twisted-pair-flat-cable-hf100-series-ts2344.pdf (not sure if the price remains affordable).
In this scenario, we could make the distance ADCboard-to-sensorboard fully twisted and have a custom section of non-twisted part for ease of separating into the various connectors for the 22 sensorboard (or more, in my case) ending into the same ADCboard

Check BOM against JLCPCB SMT parts list.

JLCPCB being one of the easier (and still reasonably priced) ways for the average person to get a board assembled, I'm trying to keep the parts used to things that are available via JLCPCB.

  • Compile total BOM. The first pass of this should probably ignore resistor values, the ones in the schematics are very hand-wavy and don't strictly match what I've used.
  • Check that JLCPCB has an appropriate corresponding part
  • Document correspondence
  • Recommend replacements for parts that aren't available.
  • Build up BOM spreadsheets or something for use with JLCPCB? Haven't had them assemble anything, not sure how that works.

In the unlikely event anyone else tries to work on this, you'll probably need to ask me some questions about part choice/suitability. Some are left underspecified in the schematic, some might be too specific. I can either describe the relevant attributes for a given part ("needs long term stability and low input offset"), or review a few choices presented to me.

Networking board Rev 0

Putting ethernet on the main board is an unnecessary complication, which increases the board size/BOM/cost/etc. Many users probably won't even want it. It's certainly non-existent on every other digital piano, so it shouldn't have such a prominent place.

I decided I2C was a nice idea after I'd already started putting the ethernet onto the main board, and didn't reevaluate its suitability. Doing full TCP/IP over I2C would probably be a pain, but the main board doesn't need to. It can mostly just worry about MIDI and its own configuration.

So we'll move all networking off to another board, and pick up WiFi at the same time. The networking board will feature an ESP32 module, acting as an I2C slave to the main board. The ESP32 will bring along WiFi, and we'll add a SPI-based Microchip ENC28J60 to get 10Mbps ethernet. The only thing that will need to move across I2C is MIDI messages (and maybe some sysex for configuration/control, but that's minor). All of the TCP/IP and RTP MIDI stack stuff can be handled on the ESP32, where it won't bother the realtime stuff happening on the main board.

Concept Verification Tasks

  • Check ENC28J60 board with a Bus Pirate
  • Check ENC28J60 board with an ESP32 module
  • Reverse engineer the now-known working ENC28J60 board.

Circuit/Layout Tasks

  • +5V power input circuitry. The ESP32 draw is expected to exceed what we'll want to provide over the I2C cabling
  • Get an ESP32 on a board, as an I2C slave.
  • Qwiic header(s). ESP32 as slave, and ESP32 as master, so it can have some devices of its own. (Or be attached to one of the buses that the main board is also mastering, for a multimaster type thing.)
  • Add ENC28J60 as SPI slave to the ESP32

Main board add RTC oscillator, battery header and appropriate Vbat circuitry

I'd like the ability to run the RTC on the main board, accurately. That'll let us track calendar time, so that we can properly time stamp files stored on the SD card.

Why do we want to time stamp files on the SD card? I'd like to be able to record everything played into MIDI files on the SD card, to duplicate the Pianoteq feature of remembering everything that's played. It's not a super high important feature, but it should be possible to at least squeeze the relevant stuff onto the PCB (with no downsides) even if it isn't populated.

See section 2.1.3 of AN4938. It looks like the STM32H743 can charge the battery a little bit? Do I need to put something in place to handle the possibility of a missing battery? Maybe a diode with a 1.5V drop from Vdd to Vbat? Or just some spot to solder a resistor between Vdd and Vbat?

So we need:

Main Board Rev 2

  • Generally review the thermal relief on the top layer to ease hand soldering
  • Specifically improve the thermal relief around the RS485 transceiver decoupling caps
  • Similarly improve thermal relief around the I2C connector decoupling caps
  • Fix silkscreen of C20 (decoupling cap for I2C J6)
  • We use lots of ferrite beads on this one. The 0805 inductor footprint is a PITA; increase to hand soldering 0805 footprint, or maybe use the non-hand soldering capacitor 0805 footprint.
  • BOM for the Pwr and Stat LED current limiting resistors should be adjusted way down. Currently 3300 ohm(!) they should be more like 300 ohm.
  • The JTAG header is 33mm x 9mm. It needs a significantly larger courtyard than was used.
  • I got the battery connector pinout wrong, because I forgot to look up the connector polarity. Just remove the battery and RTC stuff. There is at least one Qwiic RTC board available from Sparkfun, that should work just fine for anyone who wants standalone operation with correct timestamps on the SD card.
  • STM32H7 actually has special hardware support for SD cards. Rearrange UARTS/I2C/etc to get access to one of those sets of pins. Drop the use of SPI6.
  • The SDCARD_DET line was hooked up all wrong. Fix that.

Pedal board rev 1 bringup

  • TRS jack position; front face & space between jacks, and between jacks and mounting
  • General check of good behavior, as rev 0 was sort of abandoned early

Minor boards

  • Sensorboard, final schematic/footprint/layout check.
  • Sensorboard tester, final schematic/footprint/layout check.
  • LED test bar, final schematic/footprint/layout check.

ADC Board Rev 0 bring up

There are three bring up issues to check before the Rev 1 schematic can be finalized:

  • Test that the USART/RS485 transceiver work correctly. It should be fine, as I used the same symbol/footprint as the link adapter board, and USARTs are simple, but... who knows.
  • Test that the 22 channels of near-simultaneous ADC conversion works. I should really have done this sooner, as the project relies heavily on this working.
  • See if the built-in bootloader works on initial power up. The ST app note on the bootloader has some ominous warnings about V9 of the bootloader, which is the most recent, and presumably what I've got on my parts.
  • Slightly easier, see if it works on the USART pins we're currently using. Moving to a different USART probably isn't a problem, but why mess with a layout that seems ok.

Update PCB layouts with new revision number & generate gerber files

I update the board revision number right before producing gerber files. So this will be the very last thing to do on the milestone.

  • Commit updated silkscreen for all boards

Generate gerber files for the following, and attach to the release:

  • Main board
  • ADC board
  • LED power
  • LED test
  • Sensor board
  • Sensor test
  • Pedal
  • MIDI
  • Link adapter

ADC Board Rev 1 bringup

  • Check adjusted power supply filtration.
  • Check MCP120 chip.
  • Check 2V regulator.
  • Check transimpedance amplifiers.
  • Check JTAG header works right now.
  • Check RS485 wiring
  • Should put a microcontroller on to ensure that some of the rearranged digital lines are ok (the UART in particular)

We'll want the new TIA circuits for testing/writing analog processing code going forward.

Link adapter Rev 1

All the desired fixes/changes have been made. I don't anticipate bringing these up, they're just cheap enough they're worth getting in case I need more adapters; no sense building the old design.

  • Final schematic/footprint/layout check.

ADC Board Rev 2

Place to record necessary changes for rev 2 of the board:

Necessary changes

  • Bring the JTAG header in 1-2mm from the edge of the board, so that the pcb stickvise can grab the board even with that header attached.
  • Silkscreen for +5V and GND on the external power header

Noncritical changes

  • Increase thermal relief on pin 3 of the MCP120, to ease hand soldering.
  • Consider just increasing the thermal relief everywhere, to ease hand soldering.
  • Move the power LED further away from the 8p8c jack, to ease viewing.
  • Bump up the size of the electrolytic cap footprints by 1, to better match the cap selection you get in variety packs.

Possible improvements

  • Consider swapping the location of the RS485/power input and the USB connector. As it is, the +5V power to the analog linear regulator is passing under the MCU, which will act as a source of noise.
  • I realized that I was probably wrong about the suitability of replacing the voltage reference with a simple linear regulator. I can probably do an error analysis to determine how any noise on the regulator will be converted into ADC errors. I should probably do so as penance for my overeager substitution.
  • The MIC5366-2.0YC5 linear regulator data sheet only calls for 1uF caps on input and output; the schematic lists 2.2uF. That's probably fine. Should definitely keep it in mind, though, and consider it as a spot for BOM reduction.

Pedal Board Rev 1

  • Rev0 is huuuge. It can be made narrower. Maybe?
  • Push the TRS jacks back slightly, so the mounting flange on the face of the jack lines up with the PCB. Some quick measurements suggest that "slightly" is 2.1 to 2.3mm in this case.
  • Ensure that the 40mm spaced mounting holes have a setback from the board edge consistent with our other panel-mount boards. Ensure there is enough space around them for whatever mechanical solution will hold them to the panel.
  • The TRS jack footprint has an error, in that what should be the silkscreen outline is actually a line on the solder mask exclusion layer. So what initially appears to be a nice outline is actually exposed (and HASL'd) copper.

Noncritical

  • Bring the I2C bus out to a 0.100" header.

Scoring the sensorboards?

Most PCB manufacturers have a minimum size, which is much larger than even the larger sensorboards.

I guess making one PCB with scoring should solve this issue (and perhaps save some money, the way I've seen costs being calculated).

I don't see scored sensorboards in the repo though, so I am wondering if that's simply left as an exercise to the reader, or if there is any issue which my naive competence does not let me see.

ADC Board Rev 1

Most of the fixes necessary for Rev 1 have been made and are covered under the Board Revision Notes.

  • Completion of #7
  • Bring out MCO1 and MCO2 on some test points, or at least confirm that the existing test points expose some timer pins. Goal is to make it convenient to measure the frequency stability of the built-in oscillators,
  • Triple check the transimpedance amplifier design in the analog half. @DigitalExegete agreed to help. :)
  • Final symbol/footprint/layout checks.

Sensorboards hole spacing

All the centered sensorboards have the holes at a distance of 20.2mm from each other, rather than exactly 20.0mm as I was expecting for the extrusions you and I are utilizing.

This might be intentional or my own measurement error, and in any case not a big deal since smaller than mechanical tolerances, but since I saw it, I am reporting it anyway.

Main board rev 0 bringup

  • Qwiic header pass-through Every one on the main board is its own bus, this item must've predated that change.
  • Power input, reverse polarity protection & regulation
  • Control of N/P channel MOSFET array
  • 20MHz & 25MHz oscillators
  • One stack of RS485 transceiver & jacks, to confirm correct wiring (sigh)
  • Microcontroller (UARTs & I2C primarily)
  • Ethernet chip, magjack, and microcontroller use of ethernet Going to move networking onto an optional board.

ADC power supplies: linear or switching?

An inconsistency in the ADC kicad file:

image

As you can see the comment says "Monolithic switching regulator" but the part and its description is for a linear regulator.

Probably related (hence I am not opening a separate issue for that) is the text in https://github.com/jkominek/piano-conversion/wiki/Assembly-Notes which says

IF your firmware doesn't draw much current, you can use a linear 3.3V regulator, and save a couple of dollars per board. If you don't know what you're going to run on the board, stick with the suggested VR05S3V3

Not sure what you mean by "suggested", I initially thought that your board had a switching regulator VR05S3V3 which one could substitute with linear regulator, but instead it looks like it is now the other way round? If that is the case, does it mean that the regulator you selected should be able to provide enough current for a generic firmware, or that you measured the current for the firmware you posted and for that the linear regulator is adequate?

In any case, you might want to fix the kicad file and the wiki page

MIDI Board Rev 1

  • Ensure that the 40mm spaced mounting holes have a setback from the board edge consistent with our other panel-mount boards. Ensure there is enough space around them for whatever mechanical solution will hold them to the panel.

BOM-only

  • The 74LVC1G06 should be a 74LVC1G07, so that the MIDI OUT side works.

Non-critical issues:

  • Bring out the pair of ~IRQ & GND on a little header. Maybe a pair of them so they can be daisy chained.
  • Increase the space between the Qwiic connectors, to facilitate hand soldering
  • Add a two-pin header for power, to ease testing
  • If we stick with the TLP185(SE add some silkscreen to make orientation more obvious.
  • Update the TLP185(SE footprint to remove the unused pins in the middle.
  • Bring the I2C bus out to a 0.100" header.

HDLC code should use DMA for transmit

The HDLC code on the ADC board (which will need to be generalized for use on the main board as well), currently receives data over the UART using DMA. Character recognition on the HDLC frame byte is used to trigger a UART interrupt to process the received data. Works great.

But the board still uses the dumb method of sending data, with the CPU spinning while it waits. Even at 3Mbps the UART is very slow compared to the CPU (480MHz vs 300kB/s). We're burning 1600 CPU cycles for every byte, once the FIFO fills up.

Instead, we should maintain a circular buffer for DMA transmit. Note, we don't want to put the DMA transfer into actual circular mode. Rather, the send function should tack bytes onto the end of the buffer, and if no transfer is currently in progress start one. Then the DMA transfer complete interrupt handler should check to see if there are unsent bytes in the buffer, and if so, begin a new transfer.

(The code which writes into the outgoing buffer could also add in a bit of smarts, and send fewer HDLC frame bytes, depending on what it sees in the buffer already.)

That should free up quite a bit of CPU time, and work quite nicely even with the priority of the DMA transfer lowered, as the UART has its own FIFO to help smooth things over.

Main Board Rev 0

Subtasks:

  • Triple check the high-side power control of ADC boards.
  • Include a SPI memory part, EEPROM or FLASH, or something. Find a common footprint, we can worry about what size memory (or even if we'll use it) later.
  • Double check the UART pin assignments, make sure we don't have an RS485 transceiver hooked up to something that isn't a UART.
  • Final symbol/footprint/layout check. Don't forget ERC/DRC.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.