Moppy 2.0?

[Sammy1Am]

I've been inspired to refresh Moppy a bit and incorporate a lot of the features people want / have had to build themselves, but I want to keep things simple so that first-time users can get started as quickly as possible, and if anyone does want to modify / add to it, it's easy. To that end, I have a couple open questions:

Wifi or Ethernet?

Wifi (probably via the ESP8266) has the advantage of being wireless (duh), but would require some additional setup (flashing the correct firmware to the ESP8266, connecting to the correct wifi, and the ESP8266 wants 3.3v instead of the 5v that the Arduino and floppy drives are using).

Ethernet requires that you have cables, a switch, and (if you want to avoid additional setup) a DHCP server. I'm not sure yet what hardware would be easiest to use, but generally it doesn't seem to require its own separate firmware, so that might make setup easier.

Existing Protocol or Custom?

There are some existing network protocols that could be used for transmission of notes (and I think I'm willing to take another stab at getting the Arduino to decode MIDI fast enough to not interfere with drive operation). CoAP and RTP-MIDI are some UDP candidates and MQTT could be used over TCP (UDP has the advantage of supporting broadcast/multicast which might be desirable for this sort of application). Using existing protocols would make adding new Moppy devices (light show controllers?) easier since libraries would exist for interpreting / sending commands in many languages.

On the other hand, all of these protocols would involve additional overhead, and potentially make interpreting the messages more complex (ideally the average user wouldn't care much, but if anyone wanted to make changes...). Also, any protocol tied to MIDI is still limited to 16 channels, but I think it would be nice to remove that limitation.

Additional Note

I'm leaning toward moving the channel/note/track selection logic to the Arduino-side of things, and just broadcasting all note events to the network. This would require being able to configure the Arduino to set things like its number of drives, channels, etc, but hopefully that could be done over the network (via the desktop control program). The thought here is that this would make adding more devices to an orchestra easier to do since you wouldn't have to make a lot of changes on the controller-side.

Discuss!

Feel free to discuss any thoughts; again, the primary goal here is to maintain the easy out-of-the-box (so to speak) setup experience while adding a bit more robustness/flexibility for advanced users.

[solidsnake745]

I mentioned wanting to build a library to port a lot of the setup/configuration and operation to the microcontroller. I think what you're mentioning here is somewhat implemented in my library. I'd like to discuss this more in depth. Let me know if you're interested in a Skype/Hangouts meeting.

Till then I've attached the latest version of my library. Haven't worked on it in a while and still needs a good logic review FYI. v7.zip

I'm sure there is a better way to structure this, but I was having a lot of difficulty working with objects in interrupts. So everything is still in a bunch of static arrays and thus there can only be one instance of this class. It's one of the improvements I'd like to make later.

There are a number of methods for configuring devices and I've been actively using this same library for my own instruments (FDDs, HDDs, and stepper motors). I have not done a lot of testing around changing the configuration mid-operation, but theoretically it should work. We could easily hookup those methods to act on commands from whatever networking/communication protocol is used. There is a default configuration (based off the original Moppy - 8 3.5 inch FDD drives) which can be configured in a header file if users find that easier to manipulate.

I'm also thinking of building a layer on top of this library to allow for pooling. I re-structured this since I last gave it to you to be more centered around devices than MIDI channels. So that way you aren't locked into a one-to-one relationship between instruments and MIDI channels. The layer on top would let you define how to pool notes assigned to a given MIDI channel. An example configuration would be:

• You have 8 FDDs (devices) connected to a microcontroller
• Assigning notes to MIDI channel 1 distributes to devices 1 to 4 using stacking assignment
• Assigning notes to MIDI channel 2 distributes to devices 5 to 8 using round robing assignment

Potentially this could be expanded with logic to distribute notes based on preferences/priority to different devices.

[tg44]

I just watch this project, and it was years ago when I really tried to do things with it...

Wifi or ethernet? Why not both? (I have no real exp with arduinos but I don't see why you/we could not write code which works with both hardware.)

Communication: I would prefer raw tcp (rtp midi looks nice, but I think it is a huge overkill, udp has the disadvantage of loosing pockets, or modified packet order. I tried this with my rpi implementation, that was a bad idea. I think novaday really few application needs the udp speed, and more needs the tcp reliability. I think MQTT is an overkill too. If you want broadcast tcp will just enought to the number of devices we expect. Flooding the whole subnet is not so gentle especially when only 2 device is interested and 40 is not :D )

"I'm leaning toward moving the channel/note/track selection logic to the Arduino-side of things, and just broadcasting all note events to the network. " -- I misunderstood this, so maybe others will do so. You don't want to move the selection logic, you want to move the filtering and the chennel/note/track assigning - to be remotely configurable - to devices/drivers. If the initial architechture on the controller side is good, probably we could do all the fancy "port1 on arduino is a stepper motor and use it for channel 1 and port5 is an FDD use it for channel 5" kind of things.

What if the controller code could be relatively easily ported to linux based devices too? (like rpi, rpi clones, beaglebone, etc.)

I would not go that far when you can assign notes to stacking or round robin distribution. I think when you need this kind of functionality you have the bad midi as input. I have a really old repository maybe the functionality can be used in some place: https://github.com/tg44/MidiSplitter

If you need java/scala coding help, mail me :D

[Sammy1Am]

I've setup a new repo since these improvements will probably be breaking changes, and started to flesh out the messaging protocol.

@solidsnake745 :

• I definitely think we need a logic/core library, and yours would probably be a decent starting point at least from a concept perspective. I don't know if it'd be easier to use what you have as a starting place code-wise, or copy and paste parts of it into a new library to sort out some of the structure bits.
• I think configuration via header file is a good place to start, but on-the-fly changes would be a good add-on.
• I also am pushing to decouple Moppy communications from MIDI and just deal with devices (see wiki and protocol info in link above). I think pooling's a must-have for the library, but I haven't really figured out how best to do that yet.

@tg44 :

• Both is definitely good, but I have to start with one or the other since I'd like to be able to present/support an easy setup guide. After some additional thought / discussion I think keeping serial as an option is important too, so I'll probably just start with that again.
• Dropping UDP packets is pretty rare on a local network, and likewise since the spacing between messages is probably going to be large compared to latency, I don't think reordering will be much of an issue either. TCP should probably be an option as well, but requires either static configuration of IPs, or a UDP-based discovery mechanism (which sounds fun to implement actually, so I'll probably try that)
• Yeah, I misspoke / hadn't fully thought that idea out yet. I think what I really want to do is move toward a more generic output from the controller, like "Device 1, play note 24 on sub-device 3", and let the device figure out what "note 24" and "sub-device 3" mean, and whether or not that note needs to be constrained, pooled, etc. This way if one Arduino has only 3 drives, but another has 18, they can both consume the same messages from a controller and play them appropriately.
• The controller code is already Java, so it can already run on all the devices you mentioned. However, splitting the core functionality into its own library means a CLI control interface could be developed in addition to the existing GUI one.

[Sammy1Am]

Quick update

I sketched out the framework for some of the network code, and wrote a demo Java client that has 8 "drives" for testing purposes. Some notes:

• I tried to keep things simple enough that they're unlikely to be broken on your machine if you try them, but I haven't spent a ton of time actually testing, so things may be a little rough around the edges.
• Similarly there are some pieces missing / not fully implemented, but again, it should be close enough to get the idea
• A BridgeSerial implementation will probably be my next addition, but for now BridgeUDP allows for testing with the DeviceGUI
• The DeviceGUI is lame so far, but at least provides audio for testing purposes. Eventually it'll have little pictures of drives and visual indications of notes / status.

[Renarix]

Hi! You can also modify arduino code to allow 9 drives on one arduino uno. It would be very nice if you could have 2 options how song could be played- like now and something similar to mechanic sound like this-https://www.youtube.com/watch?v=yHJOz_y9rZE . Why? Because there is some floppy drives that cant keep up fast moves. It also sounds different. Anyways, thanks for this software! It is best way to recycle floppy drives! :)

[Lothean]

Hello! I'm very happy about this project, it's great to see such new things! Maybe you should consider some options to distinguish floppy drives from other steppers motors ? Like, an easier way to constrain notes on some channels only, and make a real way to set the steps of our stepper (in the Arduino sketch, it's a byte array, which only goes up to 255, so, for example, a scanner with 1800 steps because of the mechanical build is kinda hard to handle) I really hope these features are gonna be a thing, and thanks to you all for Moppy2! (And I also really hope that the Python version is gonna be a thing!)

[Sammy1Am]

@Renarix : The new Arduino code will be a little more configurable with regards to number of drives, but I'll definitely go ahead and add the 9th drive to the Uno version of the sketch (no reason not to!). As for the sound: the video you linked is how the drives sound currently. The actual result sound is a combination of factors including note pitch, the drives themselves, whether there is a disk in them or not, what they're mounted to, microphone location, etc. I'm guessing that the notes in the video you linked are near the lower end of the range, which is why they sound a little more mechanical.

@Lothean : I'm going to attempt to move some of the constraint logic down to the Arduino code so that it's more straightforward to change settings per-device. Good feedback on the step array, I'll make that an unsigned int so you can have 65k steps. As far as the Python version goes, I probably won't be contributing much myself (not much Python experience), but I'm making a dedicated place for it in the repo so that it's easier for others to contribute code.

[AmEv7Fam]

@SammyIAm One thing I noticed about the video is the heads don't seem to be moving, meaning that it's stepping back and forth.

Still, one thing that might be a good idea to mention in the documentation of the new version, especially in a video, is that the user needs to experiment with their personal floppy drives: get to know which notes they produce loudest, cleanest, etc.

Some of my drives produced the 4th octave pretty loudly; others produced the 3rd octave louder. My 5 1/4" drives produced the 1st and some of 2nd octave VERY well, better than even my loudest 3 1/2 drive.

(As a sidenote: perhaps a bit somewhere to be able to toggle moving the floppy head in place vs. full length?)

[Renarix]

@AmEv7Fam (As a sidenote: perhaps a bit somewhere to be able to toggle moving the floppy head in place vs. full length?) Yes thats what im saying. It would make some songs very nice. I guess it works like sending frequencys to motors. Example i have one drive that doesnt play correctly it just doesnt produce sound like it is meant.

[Sammy1Am]

Ah, they are indeed not moving! I missed that. You can emulate that now by setting the MAX position value to 2 for the drive in question (that'll cause it to reverse after 1 step).

If you're doing that for all of the drives, it might be fun to alter the resetAll() function to move the heads to the half-way position so it's not at the very back of the drive... not sure if that would alter the sound at all though.

[AmEv7Fam]

I think the biggest benefit for "staying in place" is for longer notes. The "ooh-whoo-whoo" effect can be done well, but it sometimes can be distracting.

If we were able to do it via a MIDI file... perhaps the volume parameter? "Volume FF" for standard back-forth, anything else for "in-place"?

I don't know how it's going to change the tone or volume, though...

[Sammy1Am]

Huh, an interesting idea. I feel like it's a bit complex to try to incorporate early on (for the sake of keeping the code as straight-forward as possible while it's ramping up), so it might be suited for its own branch or future work.

That said, velocity should probably just stick with velocity (in case someone wants a device that can do dynamics), but a MIDI "Control Change" message might be a good place to put a "move-head/don't-move-head" command in a MIDI file. The Moppy-side of things wouldn't be too hard, just a device message that sets the max position value for a drive (useful also for configuring drive maxes from the controller instead of the Arduino code).

I've added it as an enhancement in the new repo (the very first issue!).

[AceoJack]

Hey. I was looking through my email thread of this conversation about Moppy 2.0 and I had some thoughts. (By no means am I good with code or engineering just thought you might want some suggestions)

1. When I was building the 16 floppy version, I found it hard to setup and use. Maybe add a bit more to the UI if possible so it is easier for people to do this project. This might help new comers want to build and join the forum.

2. Could you add a version for other supper motors. Maybe add into the UI a drop down menu choosing either a floppy drive or number of steps your motor has. This could be useful for people with printers of basic stepper motors and could add a variety of sounds. I have no idea how you would be able to code this in anyway but if it is possible, it might be worth thinking about.

3. I found when I was first downloading the files from github, I found some of the files confusing because they were all named quite similarly. Maybe have a folder with everything you need and have files that are for each step. This would be good for first time setups and could make things less confusing and limits the amount of issue threads there are.

//I was also thinking that the UI could have some 'decoration' but that's probably not the highest of priorities. I was just thinking if you wanted to publish Moppy 2.0 it might want to be nice and crisp looking. It's fine either way and I will still love it haha//

Thanks for still being actually active and not just ditch the community like some project makers. I am looking forward to seeing what the beloved Moppy becomes.

[Lothean]

I was thinking about other ideas too Because Moppy is becoming more a "computer orchestra software" rather than a simple "floppy drive musical controller", why not implement drum support (with hard disks read/write head making drum hit sound) ? It would make the tunes more dynamic (see the Floppotron!) Not sure about this one, but also from the Floppotron, an enveloppe simulation mode, which turns an Arduino into a unique floppy drive channel but with enveloppe simulation, for very big setups (I doubt anyone will approve this but hey fingers crossed) Last idea and I promise I'll stop bothering you, if Moppy is becoming more a universal hardware music player, maybe another name would be more appropriate ? :) I know I have ideas but no contributions, but my next school year is in a special programming university, and since I have the basics for most languages, it's gonna be pretty straight forward for me, so I will contribute to Moppy2 in the same time as I learn more and more things, since it's a beloved project to me and I use it alot.

[Sammy1Am]

Hey, I do love contributions in code-form, but good ideas are good ideas, so they're all welcome :)

@AceoJack : What sort of troubles did you have when setting up 16 drives? The UI was previously, admittedly, a bit rough, so I'm hoping to do a cleaner job this time. What would have have been helpful for getting you started quicker?

With regards to drum / relay / stepper motor stuff, @solidsnake745 Has done some great stuff with the Arduino code for supporting different output devices and the like, and hopefully we can bring those improvements to Moppy2; it'll be a little challenging to make those options configurable from the UI rather than by changing variables in code files (which is probably where it'll start), but it's not impossible.

I'm hoping to be able to provide a pre-compiled .jar file this time around, which should significantly reduce the number of files you have to download/deal with (and no NetBeans requirement!). The trade off here is that any sort of troubleshooting will require a bit of extra bootstrapping to download the source and an IDE.

Regarding the name: The aim here is definitely to break away from being a floppy-drive-centric application, but I think remembering your roots is important. I mean, look at AT&T (The American Telephone and Telegraph company) or 3M (makers of ... well a whole lot of things, but originally the Minnesota Mining and Manufacturing Company (an excellent answer for Scategories too, by the way))

Looking forward to a pull request or two if you decide to contribute, @Lothean !

[Renarix]

@SammyIAm Wish you luck! I really want drum thing became reality with hard drives or these drum things :)

[dmadison]

I'm late to the party, but once again I'd urge you to add a proper license and make the code open source. As it stands, you could make the repository private tomorrow and no one would have any right to use the software. I had a few improvements I wanted to submit myself but hesitated because the software isn't open source.

[Sammy1Am]

@dmadison I'm sorry you're unwilling to contribute without a license in place. It's in my todo list to take a look at licensing at some point, but since we're pulling in some external libraries, I'll have to make sure I can get something compatible (and features and bugs are taking priority at the moment).

[MuffyTarkin]

What I'd love is an option to easily remove the current note ceiling. Moppy is really versatile in how you can use it to interface with other devices, and in my own experience these other devices are capable of hitting much higher notes than what Moppy forcibly limits them to. Take for example hard drives. They're just functioning as speakers and they're playing back waves generated by the Arduino, but the waves are still limited to what Moppy allows the Arduino to process. This is somewhat annoying because even though it's just a speaker and can theoretically play any note, anything above the note range is just clipped out or pulled down an octave. To people with untrained ears it sounds fine but for the musically inclined, it's noticeable and it's annoying.

As for interfacing and communication, I believe the new Arduino 101 has built in wireless capabilities. That might be worth investigating. And they do work with Moppy. EDIT: Yeah, looks like the 101 has built in bluetooth. Alternatively I wonder if a wifi shield would be an applicable tool for true wireless. EDIT 2: So it looks like 101's no longer exist, apparently Intel quit making chips for them. Oh well.

[MuffyTarkin]

Oh, another awesome feature would be allowing us to play-back MIDIs in real time within DAWs like FL Studio or Reaper. Instead of making the changes to the MIDI within those programs and then exporting the MIDI, then loading it up, connecting, and playing the MIDI, it'd be a lot easier in terms of workflow if Moppy could be detected within these programs as a MIDI device that could accept MIDI outputs from within the program. This way, you can just play a specific MIDI output on a specific channel without having to go through that whole process of exporting and running it through Moppy. Would make finding problem notes on specific drives a lot easier.

E: If this feature already exists, I'd love a guide on getting it to work because it would make my job a lot easier lol.

[Sammy1Am]

@MuffyTarkin : I'm moving the note-number to output mapping into the Arduino-side of the code, so that devices that have different ranges (or capabilities) can do their own mapping. This would allow e.g. a HDD device to synthesize its own audio in response to notes. (You can remove the ceiling in the current 1.0 code by just filling in the additional period information in the Java code, but I can see why that's not an ideal solution)

The current version supports using MIDI as input already. My memory is a little rusty, but I believe up near the synthesizer controls there should be a "MIDI In" option. This allows you to receive MIDI notes directly from a MIDI port. Depending on your setup, you might need to get a virtual MIDI cable that allows you to connect MIDI devices within the same system. This wasn't a high priority for me in 2.0, but if you're getting good use out of it, I can see about getting it added sooner.

[MuffyTarkin]

@SammyIAm Thanks! After posting that I actually did a quick search and saw @solidsnake745 had already posted a guide in reply to someone else on configuring FL to output to Moppy. You need an external program that creates a virtual MIDI port but no biggie, I'm glad you had the foresight to allow MIDI input instead of files. On the subject of the note filter, in my own testing using MIDI input from FL, as long as constrain notes is unchecked, the notes that are normally out of range end up being processed so really that's a non-problem for me now, but it'd be nice to have a system like what youre describing for folks that don't have access to a DAW or have limited understanding of editing Java to get around it.

Now, there is an odd problem I've noticed as I've been using Moppy over the last year. I noticed some notes just straight up don't play. It seems to be related to notes surrounding it. I'll provide an example of this shortly as I've found an exact demonstration of this in a song I've been working on. At first I thought it was related to note length (if a note extends into the start of a following note that following note will be skipped) but in this example, even adjusting the note length and moving the following note further down the line still didn't cause it to be played, so I think there's more going on than just note length effecting it. I'll create a separate issue thread for it. If it's something that can be fixed in Moppy 2 that'd be awesome.

[Renarix]

Hi! Does armed floppy eject system change sound? Here is sound file of power rangers remake played by my floppy drives. Seems like some of channels cant be heard maybe... Of course everything is functional :D theme.zip

[MuffyTarkin]

Not all drives will sound the same. Some are louder, some are harsher, some are buzzier, some play awesome bass and others can handle those lower C5 notes like nobody's business.

To answer your question, yes. If you arm the ejection system that will most assuredly make them louder. Leaving them enclosed in their metal casing also helps if you decide to stack your drives. However there is a trade-off here. I record my drives with a high quality TASCAM recorder, and when the enclosure are on and the ejection system is armed, a LOT of the lower bass frequencies just don't come out. No matter how much the audio is tweaked and adjusted.

For general purpose live viewing, I'd arm the ejection and try to keep as many as you can enclosed and stacked. But for recording, if you're using high quality mics and want to bring out some of that hidden grindy bass, open them all and leave the ejection system unarmed.

E: Also, another hugely important thing to keep note of: even though floppy drives are monophonic, there are still ways to hugely improve variety with them. I've noticed that most people getting into this kind of thing have a tendency to just drop octaves and copy and paste a few channels across all their drives. That's a good way to get a general idea of how it might sound, but you can make it sound much better. Take chords, for example. I'm musically stupid so I'll just throw some examples. Let's say in one bar you have 3 notes all playing on top of one another, let's say C4, A3, and G3. Floppy drives, being monophonic, and Moppy, being intelligent, will only process the first note it sees out of this chord. In this case, that would be the C4 note. So you can duplicate that whole chord to the rest of your drives, but it'll still only play that C4 note. It will increase in volume, but there won't be much in the way of layered variety.

Something I've been doing is going the extra mile and separating chords out from each channel. So let's say you drop in a MIDI that originally only has 3 channels, but one of those channels has nothing but tritone chords in it. What I'll do is separate those notes out. So I'll take all the top notes from each chord and move them to their own channel, and do the same for the notes in between. At the end, I'll now have 3 new unique channels that are all playing their own notes to complete the chord, plus the two other unique channels for other parts of the song. The end result is more volume AND that additional variety from creating a more layered sound.

This is just an extremely time consuming process, and can get very confusing if the track you're working in features multiple types of chords, ranging from two notes all the way to 4 or 5. You have to keep a kind of consistency down with what notes you strip away and move, and if chords only show up in specific sections, it's even more time consuming because you'll want to keep those unique chorded notes and also include everything else around it so you don't end up losing necessary volume on an important channel. However, it is very much worth it if you feel like going that extra mile. The sound these can produce when playing chords is really cool.

Of course, this goes beyond chords as well. I've seen a number of MIDIs out there that will have important melody notes stuffed below a bunch of other notes that are being covered by other channels out there (just because it was made with a particular MIDI patch in mind to produce a specific kind of sound). In these situations, those melody notes won't even be seen by Moppy. To make them be seen, you'll have to go and pull those notes out and put them in their own channel. When I work on a song and plan on doing a video for it, I usually spend at least an entire day (maybe 5 to 8 hours or more) just working on the MIDI. That's separating chords, bringing down specific notes to prevent the drives from squealing and squeaking, moving channels around, pasting note sections elsewhere, singling out specific drives and moving tracks around to what drives play what best, trimming note lengths at certain parts to create a more "instrument" like sound instead of just a crunchy, grinding droning sound, etc. I also have a number of other "instruments" too, like hard drives, a steam controller, a scanner, and soon to be a tesla coil, so there's much more for me to do in the way of experimentation to see what sounds best. Sometimes I can nail all of these, sometimes I can't. When it's 3 AM and I'm tired of working on it I usually call it quits and say it's good enough. Of course, if you don't plan on doing any videos or just want to have fun screwing around, there's probably no reason to go THAT far into it.

[Renarix]

OH ok... its is hard to understand that for me but i get it.

[Renarix]

Moved to #183 - @SammyIAm

[AmEv7Fam]

To add to what @MuffyTarkin was saying...

I've actually got a couple drives that get a tiny bit louder, and add some serious overtones, to the point of sounding like an octave or two being transposed up, by lowering the eject mechanism without a floppy disk in it.

There's some tweaking that we're working on, on the new repo, that allows for spontaneous changing between going the full length of the head, and just stepping a couple places, as we've found that creates a more undertone-y, bass-ier note.

Nonetheless, that's my number one piece of advice: Get to know your drives, know what notes (and ranges) they produce best, know which configurations allow them to be the dominant note.

PS: I've actually got a floppy drive that uses a motorless actuator to move the head. It's stupidly quiet: good for desktop use, crappy for floppy organ use... except maybe as a visual device.

[fedoroff-aa]

Hello! I am new in this theme. I used your first version, but now, thank you for the second version of moppy. I am using arduino. I put the sketch from your package and now I have a porblem. I don't know, how to use the java files, well... I don't know how to open them, cause for netbeans it is not a project, cause it doesn't have xml file. I hope, you explain me, how to use the java project you provide.

[Sammy1Am]

You'll need to install the "Gradle Support" plugin to load the Moppy2 project in NetBeans.

I've switched to using Gradle as it allows for better dependency management (for external libraries like serial communication) and because it doesn't require NetBeans (other IDEs should work just as well)

[fedoroff-aa]

Ohhh, I didn't wait for SUCH fast answer right from the creater, thank you very much) And well, if you are here... How to use HDD and scanner with this software, if it's possible? Cause I want to have more sounds) And the other question is, will the software work with the arduino mega? Just I want to order it and connect more FDDs to have more channels and to make my unit louder. Or how can I jump through the limitations of 9 drives?

[Sammy1Am]

@AlekseyFedorov25 First, I saw you had some other comments here previously-- you just need to make sure you also open up the MoppyLib project in NetBeans as well so that it can build them together.

Will it work with HDDs?

Sort of? It depends on what you mean by "work with HDD". If you directly connect the step output to the driver coil, I think think in theory it would play that note (just the same as if you hooked it to a speaker), though you might need some sort of amplification to get enough power. If you want the HDD to tap more like a drum, you'll need slightly different code on the Arduino side. I'm working on code that would be pretty close, but it's not going to get finished before the holidays.

Will it work with a scanner?

Should work fine software-wise, though the maximum position should be adjusted to much higher than 158 to match the scanner. The biggest trick with a scanner is you'll need to provide your own stepper motor controller (or somehow hijack the one already in the scanner).

Will it work with the Arduino Mega?

Absolutely yes! No modifications required for up to 9 drives, and if you want more than 9, you just need to extend the Arduino code to account for the additional drives/pins/etc. It should be relatively intuitive where to extend things. MIDI files have a limitation of 16 channels, but with Moppy2 you'll still be able to use as many drives as you'd like (err, I guess only up to about 65,000 drives, but that's probably enough ;) ). You'll have to come up with a Mapping Script to map 16 channels onto more than 16 drives though. Maybe two mappers where the first has a subAddress of c*2 and the second a subAddress of (c*2)-1, which would basically assign two drives per channel.

[fedoroff-aa]

Thank you very much for answers again, now it works perfectly, I just worked with panel "options" and no errors with gradle))

About HDDs, I didn't mean the main motor, on which disks are rotating. I meant the second type, when hdds are making a drum sound using reading module. Thank you, that you're working in this direction, don't hurry, better slower with less bugs, than faster with not-compiling code)

[Sammy1Am]

better slower with less bugs, than faster with not-compiling code

Man, I wish more people felt this way! Back from my holidays now, got some home improvement to do, and then I'll be back at this.

[DefectX11]

Hey folks! I've been keeping an eye on this project since I first fiddled with it 5 or 6 years ago. I packed everything up into a carrying case to have it as a sort of portable instrument of sorts. Went well, but life got in the way, and my soldering skills back then were lackluster, so it's fallen into complete disrepair. I tried also to work a scanner into the mix, but got caught up with a number of other things and so never completed it.

Point is, I'm really glad to see there's interest in using other computer hardware for "alternative" uses. I saw a video recently where someone had used the actuator in a hard drive as a form of percussion. Even had another arm tapping the side of the platters for a "cymbal". Sounded great, and I'm very excited to see how it can be worked into the program. As I understand it, you'd just need to supply enough power to the voice coil in a burst to get the arm to "smack" the end of its range. If so, could we just use a digital out and switch a transistor with that? Some quick into online seems to indicate 12v 600mA is enough to move the arm (and lift something with it), so it would just be a simple momentary burst of current to the coil to actuate the arm, and have it spring loaded to snap back with a rubber band or something of the sort.

I've got time now and into the summer months to do a complete overhaul of my Moppy setup, and so if there's some help that you need, please let me know. For now, I'll just work on getting my hardware back up to scratch. A few questions though:

If someone has had success in getting a scanner to work, could you compare the sound output level to that of the floppy drives? And, what scanner did you use? Given the size of the hardshell case I have to fit everything inside, I'm planning to use a Canon LiDE scanner. I've gotten it stripped down to the necessary bits, and rewired the stepper motor, so I'm just waiting on the stepper controller to show up and then I'll have some time to fiddle, but I'm worried (given the small size of the built in stepper) that it won't be as loud as I hope.

Can anyone provide a rough estimate of the current draw per floppy drive during playback? I'd like to make sure I don't overload the 5v rail on the PSU I'm using.

[ahnafr]

My guesstimate suggests that my floppy drive(s) draw about 2 watts each.

Good day/night to you,

Fellow Moppy user. From: G Sent: 12 February 2018 02:19 To: SammyIAm/Moppy Cc: Subscribed Subject: Re: [SammyIAm/Moppy] Moppy 2.0? (#179)

Hey folks! I've been keeping an eye on this project since I first fiddled with it 5 or 6 years ago. I packed everything up into a carrying case to have it as a sort of portable instrument of sorts. Went well, but life got in the way, and my soldering skills back then were lackluster, so it's fallen into complete disrepair. I tried also to work a scanner into the mix, but got caught up with a number of other things and so never completed it. Point is, I'm really glad to see there's interest in using other computer hardware for other uses. I saw a video recently where someone had used the actuator in a hard drive as a form of percussion. Even had another arm tapping the side of the platters for a "cymbal". I've got time now and into the summer months to do a complete overhaul of my Moppy setup, and so if there's some help that you need, please let me know. For now, I'll just work on getting my hardware back up to scratch. A few questions though: If someone has had success in getting a scanner to work, could you compare the sound output level to that of the floppy drives? And, what scanner did you use? Given the size of the hardshell case I have to fit everything inside, I'm planning to use a Canon LiDE scanner. I've gotten it stripped down to the necessary bits, and rewired the stepper motor, so I'm just waiting on the stepper controller to show up and then I'll have some time to fiddle, but I'm worried (given the small size of the built in stepper) that it won't be as loud as I hope. Can anyone provide a rough estimate of the current draw per floppy drive during playback? I'd like to make sure I don't overload the 5v rail on the PSU I'm using. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[DJthefirst]

I am planning to build a musical DRSSTC and have seen many drivers use midi usb to communicate with the teslacoil. would I be able to use one of the existing teslacoil boards with moppy to control it and floppy drives or a drum set?

[Sammy1Am]

psst Anyone interested in helping me get some early feedback (especially if you're a Mac user since I don't have one of those to test on): I've got a test build of Moppy 2 up.

@DJthefirst , With the current (1.0 version, the one in this repo), you can set some of the channels to output to a MIDI Out instead of the serial port. If that MIDI Out was wired up to an existing teslacoil board, you could sync up the MIDI being sent to the teslacoil and the notes being sent to the floppy drives. If you do manage to get this working I'd love to see a video! (Incidentally this isn't something Moppy 2 can do yet, but I'll add it to the list ;) )

[Chong-McBong]

i just got my old 16 channel setup working again, i am up for a bit of testing of 2.0. i'm planning to add various types of drums, and probably some midi stuff at some point too,

definitely looking forward to updates - i don't have a mac, but i will help if i can :)

[Sammy1Am]

Well if you have time, download the beta build of version 2.0 from the link in my last comment. It should be a drop-in replacement for the Arduino and PC code so in theory it's an easy setup.

I'm mostly trying to make sure it works on computers other than my own before focusing on new features and better instructions.

On Sun, May 6, 2018, 14:44 Chong McBong notifications@github.com wrote:

i just got my old 16 channel setup working again, i am up for a bit of testing of 2.0. i'm planning to add various types of drums, and probably some midi stuff at some point too,

definitely looking forward to updates - i don't have a mac, but i will help if i can :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SammyIAm/Moppy/issues/179#issuecomment-386918215, or mute the thread https://github.com/notifications/unsubscribe-auth/AAci-Jef4jKqpQe0RZB6bAI8bcWh7PqUks5tv26lgaJpZM4QGah6 .

[DJthefirst]

Another thing allot farther down the road. Could we possibly designe a pcb with support for this program. I do not currently possess the skills but in a year or two it might be a good project to start on. That way for more perfesional setups you could connect the drives,power,and other devices through one board with screw terminals and headers.

[RedFox1177]

It shouldn’t be too hard, I could just throw together an Arduino Shield that has the right outputs. Power might not be possible, but I’ll see what I can do.

[Lothean]

It would be more efficient to do a standalone board with the uC integrated

[DJthefirst]

It should be easy to just copy a standard arduino board change the headers and add better voltage regulators. However I don’t know A way that you could intigrate the ide or usb midi support. But the arduino shield should still help with smaller mounting.

[Sammy1Am]

It's actually been done (at least) twice already! (The Internet is an amazing place)

• Dave on "Parts Not Included" has a floppy-drive breakout board he built for his project.
• And Rupert was featured on Hackaday with his Moppyduino board that actually includes the Arduino right on the board.

If you wanted to actually run the controller application on the same box, you'll probably need a... uh... macrocontroller?-- A real CPU. @Chong-McBong has done this already using Moppy 2.0 and a Lattepanda.

As you guys have pointed out, power is the biggest potential issue. Floppy drives don't consume a ton, but it's not the the best practice to drive them directly from the Arduino. That said, if your Arduino/Lattepanda requires a 5v power supply anyway, you can just hook up the controller and floppies both to the same (adequately amperaged) power supply.

[legop3]

hey, new to github and moppy. I was wondering if someone could help me out with using a HDD's arm as a sort of percussion instrument. what parts of the code do I need, and how to I make the software recognize it? thanks in advance.

[Sammy1Am]

Huh, should have closed this thread before as Moppy 2.0 is a thing now. Sorry for the confusion.

@legop3 , if you don't mind posting again in that repo, I can at least point you in the right direction (though I don't have first-hand experience)