Multiple Ball Drops (Parallel Processing)


#1

Any thoughts on having more than 1 ball at a time running through the circuit? Obviously you cannot have 2 of them hitting certain pieces at the same time (ex. ramp, crossover, etc.) and you also cannot reliably determine exact timing of each one as it moves through the path. These 2 facts are enough to really complicate the idea of multiple balls and make it an extremely limited possibility. However, in some controlled and limited capacity it seems like you could. For example, where the Blue & Red tracks are separate, you could have them being released together. It also seems like it would be safe enough (little-to-no risk of 2 balls reaching the same piece at the same time) if you released the 2nd Blue ball when the first Blue ball was halfway through its circuit.

Anyway, I was thinking about this and how cool it would be to see multiple balls descending the ramps, flipping switches, and turning gears, and also what additional options and puzzles this idea would open up.


#2

I think what you’d need for this is a synchronisation part which stops one ball and waits for a second one, and then releases both of them when the second one hits (probably one going left and one going right). Otherwise, as soon as you’ve got two balls in the system, the different timings of the paths (and the general variance of how quickly balls move through the machine) are going to cause all sorts of trouble.

Edit: Also, the idea of releasing the second ball before the first one hits the lever is really interesting computationally, because it means that each ball has to trigger the release of the ball after the next. But in this setup it seems even harder to ensure that the balls don’t catch up with each other.


#3

Yeah, the variances in speed of 2 balls moving through even the same path is enough to make this very tricky and limiting at best. Perhaps the multiple release is only done once manually when the first ball is halfway through the system. Or if the Blue/Red ball tracks are completely separate, then they can both be triggered manually at the same time (perhaps as a program where the Blue/Red balls race each other to determine which process is faster).

Edit: I just like the idea of seeing & hearing multiple balls moving through the system and what possibilities this concept might open up. And so, while there are rather large obstacles for this to be a possibility, I though I would post this here to see what ideas others might have about this.


#4

Oh yeah, it’s definitely an intriguing idea. :slight_smile: Just saying it probably needs some additional dedicated parts to allow for any meaningful computation.


#5

Well, parallel processing does not necessarily require cycle synchronization (waiting for the other ball). I have already been working with separate blue and red path triggering and cross-triggering, it’s fun


#6

Can you provide an example of this cross-triggering? I would be very interested to see that. How did you handle the variance in time whereby cross-triggering might occur at an inopportune time with regards to other balls?


#7

Right on. This could be pretty cool. Especially if the TT board was larger and able to fit more parts.


#8

Wow, menderbug, I see you’ve already thought through this before:

http://esolangs.org/wiki/Marbelous

Very interesting stuff! You’ve given this sort of thing a lot of thought. In your opinion, what would you like to see next? A new part? A bigger board? Something else entirely? Awesome that you’re here on the forums.


#9

I’m only about 40 puzzles in right now, so I’ll probably get back to you on this once I get to the puzzles that start to push the boundaries of what’s currently possible.

In general, a new part will probably open up a lot more possibilities than a bigger board, but I currently don’t have anything specific in mind that wasn’t already suggested in other threads. The one thing I wish I had a couple of times was a part that can only be pushed by a gear in one direction (so turning the attached gear bit back wouldn’t affect this part). Basically a one-time switch in the lifetime of the machine. This can be set up using several gear bits though (although I think the construction ends up being quite large).


#10

@Randy I fire up both blue and red triggers, the red ball may kick off the blue trigger and vice versa. Granted, collisions may occur if not controlled-for, but if the setup is complicated enough to where path cycle time/paths are long, then it is ok. Actually I have not had a collision in my experiments thus far. The longer the cycle time, the safer. To that end, I implement any little delays i can (e.g. releasing balls in the up-ramp direction at the bottom of the paths).

The proper and comprehensive solution would consist of some sort of pre-loaded gating mechanism/part. As @paul pointed out, larger boards would also help . In short, I have nothing bullet-proof to share, just having some fun with parallel processing :slight_smile:


#11

I have made a program that uses multiple ball drops to check if one of the ball types have run out.

(you start the program by placing a marble on the left side, waiting for the ball to go about half way down ,then press the right lever.)
https://www.lodev.org/jstumble/
board=rlebgbeelbreerrlleelireeleerelfrrfelrflereelee_20_16
(this only works on turing tumble, not the emulator.)


#12

@nave I’m not sure I understand what exactly your program is supposed to do. From the looks of it, any ball you release will go right to the interceptor. Am I missing something?


#13

sorry I translated it to the emulator wrong ,the corrected version: [ https://www.lodev.org/jstumble/?board=rlebgbeelbreerrlleelireeleerelfrrfelrflereelee_20_16]

correctly the program should place the ball color ,that has the most marbles, in the interceptor.


#14

I’m just going to drop this video here as an example of parallel processing, I don’t think I’ve shared it before:

As you Randy said in the original message, two balls hitting one piece at the same time is a problem. In the video I use a single gear bit where one would normally have a ramp because it’s faster and some extra speed was needed to avoid collisions.