ingie

aye, i tend to agree... although i do think it's by design so one can build, as you say, a custom purpose lite-OS

but this is why i set in my configs for the disassembler to always return all bits... in case i derp my assembly in that way...

i build robots IRL for a hobby, so if i can disassemble one without losing bits [unless i'm drunk ]  , so should a machine

at least that way you can disassemble the robot, then the memory, then change it... 

aye, but the calling routine should be checking the return value and exiting gracefully based upon that value...

But vanilla noteblocks are so much cooler

hehe.... yeah, i do think it's a shame the iron note blocks don't do the musical particles... 

aye, but with the iron noteblock, one can do playNote(instrument, note) and therefore not have to worry about what the block is standing on...

- also, for some reason, you get an extra instrument... instrument 0 is more "harpy" to 5's "piano" 

i made a start on writing a polyphonic Matrisequencer last night...  i'm using multiple note blocks for "surround sound" polyphony, and assigning each note in a chord to a different note block... this way you can stand in the middle of them and spin round and get a Leslie speaker effect... 

below isn't how the sequence pattern will work, it was more my prototyping just to check what i needed,

i'm going to change the way the "sequence" table works away from needing a duration, and instead make it phrase/bar based, with the tempo markers/time signature changes within the table so that the table can be independently transferable - mainly so i can have an "output computer" and a "programming computer" - so that the time dedicated to updating the touch screen on the programming computer doesn't effect the timing of the musical pattern player....

--[[ seq.lua ]]--

local component = require("component")

local loadDevices = function()
  local devs = { }
  for k,v in pairs(component.list()) do
    if v == "iron_noteblock" then
      table.insert(devs, component.proxy(k))
    end
  end
  return devs
end

local devices = loadDevices()

local tempo = 240

local lengths = {
    br = 2,
    sb = 1,
    mi = 0.5,
    cr = 0.25,
    qu = 0.125,
    sq = 0.0625,
  }
  
local duration = function(tempo, name)
  return 1 / (tempo/60) * lengths[name]
end

local instruments = {
  harp = 0,
  bd = 1,
  snare = 2,
  rim = 3,
  bass = 4,
  piano = 5.
}

local keys = {
                                                          Fs1 = 0,  G1 = 1, Gs1 = 2,  A1 = 3,  As1 = 4,  B1 = 5,
  C2 = 6,  Cs2 = 7, D2 = 8,  Ds2 = 9,  E2 = 10,  F2 = 11, Fs2 = 12, G2 =13, Gs2 = 14, A2 = 15, As2 = 16, B2 = 17,
  C3 = 18, Cs3 = 19,D3 = 20, Ds3 = 21, E3 = 22,  F3 = 23, Fs3 = 24
  }

local sequence = {
    { inst="piano",   notes={"C2", "E2", "G2"}, length="sb" },
    { inst="harp",   notes={"D2", "A2" }, length="sb" },           
    { inst="piano",   notes={"E2", "G1"}, length="cr" },          
    { inst="rest",    length="cr" },          
    { inst="harp",   notes={"G1", "B1", "D1"}, length="sb" },  
    { inst="piano",   notes={"D2", "F2", "A2"}, length="cr" },      
    { inst="rest",    length="cr" },    
  }
  

local play = function( seq )
  
  for _,event in pairs( seq ) do
    
    dur = duration( tempo, event.length )
    -- print( event.inst, event.length, dur)
    if event.inst == "rest" then
      os.sleep(dur)
    else
      for i, note in ipairs(event.notes) do
        -- print(note)
        devices[i].playNote( instruments[event.inst] ,keys[note])
      end
      os.sleep(dur)      
    end
    
  end
  
  
end

while true do play(sequence) end

  

you couldn't have been using those programs for that video tho  

[ as my example requires you to press "p" to make a note play ]

but that's by-the-by... i'm guessing you used a simpler thing, it's obvious that there is a lag there, perhaps it's to do with how the adapter works.

did you try my suggestion of using Computronics' iron note block? as i say - that seemed to work perfectly for me [ in 1.7.10 ] 

i.e. i'm using 

play = component.iron_noteblock.playNote

majorTriad = function(root) play(root) play(root+4) play(root+7) end
minorTriad = function(root) play(root) play(root+3) play(root+7) end

majorTriad(1)
os.sleep(0.25) 
minorTriad(3)

.. which does it perfectly  

i've updated that page, TwoThe

http://ocdoc.cil.li/api:robot

i've added a paragraph at the top which goes some way to describing the difference... it's perhaps not as clear as it could be, but to make it any clearer it really would need a whole new page adding in the components section for the robot's lower level component api and linking to that instead... but that seems like overkill - and hopefully the way i've described the differences for the few cases i've detailed explains the other cases one might encounter. 

... i was being a derp anyway, i was looking for the edit button which was on some of the pages, hadn't seen the pull-down option for it

Hi,

I logged into the wiki to clarify sangar's point - as the robot api page pre-amble is a little out of date, or perhaps unclear, but I don't seem to be able to edit that page  :/

any reason why Sangar ?

Darthhose,  if you're using goto, then you might want to consider rethinking the code...

i appreciate, however, that this isn't always obvious to a beginner... if you have an example piece of code which you think needs goto, post it here and i'll give you tips on how to avoid goto altogether... 

i've not used goto in code for over 20 years [ from using VB3 in banking systems development ] and i can't say i've ever missed it

it's not that it doesn't have a purpose if the code is a "very quick hack" - but for better structured, functional and reusable code, it's evil and should be avoided... 

[ i didn't even know lua was evil enough to have the statement in its syntax until i saw a similar post re: goto last night here ] 

i'm not saying this with any arrogance, i'm just saying - if you're learning to code, best to not even know that goto exists, it'll work out better for you in the end, and i'm happy to help with anything you think that needs it... just post an example here, and i'll reply with an alternative - and an explaination...

p.s. this has really made me want to do more music in MC - thanks for the inspiration!

i thought mine was perfectly readable

- but my intent with the formatting was so it was copy-pastable into the lua prompt as a quick test, hence how it require the "requires"

anyway... that aside.

if you use the IronNote block from 1.7.10 Computronics - compatible with CC 1.64pr4 and OC , it works - simultaneously all the time

just tried it.

but that's only if i don't use event pushing...

if i use event pushing, then i get the chord of played twice with a lag

i.e.

[ on OC ] play = component.iron_noteblock.playNote 
[ on CC ] play = peripheral.wrap("iron_noteblock_0").playNote  -- assuming the block is on a modem, and the first one

chord = function() play(5) play(9) end

chord()  -- this plays simultaneously, ALL the time, on CC and OC in 1.7.10 - yeay

HOWEVER  if i do this with event triggers - OC only of course, it didn't work.

i.e. as soon as i do

event.listen("note", chord)

computer.push("note")

it now plays the chord twice, with a 1 second lag, and not always at the same time... 

something funny is happening in the event chain there for sure, which i thought was a bug

OR so I thought. but this was because i'd [ in my lua session ] defined that listener more than once, whilst i was hacking about and testing... 

i think what's happening with your example code - when it runs out of space after running it multiple times, is that each time you call event.trigger( name, function) 

it pushes another event listener onto the stack, best to call event.ignore before the listen... 

the issue you have with the computer.pushSignal delay, is that when a signal is pushed, as per the wiki for that function, the events are processed in FIFO order, not simultaneously... 

but in general... use computronics iron note block... it seems to easily cope with 2+ notes at once... 

i.e. i can do

lua> play = component.iron_noteblock.playNote

lua> play(5) play(9) play(12)    and it consistently, plays the major chord with no delays or anything )

not sure i really understand the scenario...

why is "return value" not appropriate?

Heh, yeah, they're still experimental, so no big fanfare just yet There are quite a few things that still need doing, such as making them use energy, and probably make them insertable into disk drives to allow charging them and editing their file systems.

 

docking station... a docking station... so that you can sit your tablet down and poke it while it recharges and reclines at a nice angle...

[ i just like to make extra work for you ]

when you say that the projectors can be rotate about the Y axis... that doesn't a. work for me - i've hit them with several wrenches ... or b.  make sense... well, it makes conceptual sense, but isn't the Y axis the vertical up down, so rotating about that axis is just, well, the same as making hologram voxel(1,1,1) >  (48,1,1)  >  (48,1,48)  and is nothing more than a translation within the voxelmap itself, etc or am i misunderstanding that... 

edit: aha, it does work... i had to use an IC2 wrench... i don't really use IC2 ever these days... the crescent hammer is my "wrench for all seasons" though, and that didn't work when i hit it... and now i see it is just about the Y axis... and i presume therefore is just a proof of concept [as i still can't see a use for that - other than having a robot underneath hitting it every 2 second to make a nice "rotating hologram" effect - which goes nice with my up and down offset thingumy ]

edit2: righty... i now have a robot underneath hitting it with a wrench... and having it bob up and down and rotate is... well... interesting ) 

this is going to make me run out of wrenches/bronze very quickly though, since the IC2 ones have damage... 

it's odd that you say your issue was "fixed" as that's not what the CC parallel api does...  

you must realise that lua isn't multitasking in a true sense, it's cooperative multi tasking, in that it can only do the "other task" when the first task isn't doing anything... i.e. has yielded or ended...   as lyqyd said on the thread you cite, the "solution" with parallel should actually work *less* well than just calling the two note playing lines one after the other...  if you look into what the parallel API does, it's just a wrapper for coroutine.create / start and status checks... it's not doing anything magic [ or actually parallel, apart from keeping the coroutines managed ] 

to replicate - with less lua overhead than CC's Parallel api, just do: [ i'm writing this in a way it can be just poked into an interactive lua session ]

t = function() while true do component.musicblock.trigger( math.random(1,24) ) coroutine.yield() end end
c1 = coroutine.create( t )
c2 = coroutine.create( t )
play = function() while true do  if keyboard.isKeyDown(keyboard.keys.p) then coroutine.resume(c1)  coroutine.resume(c2)  end  event.pull() end
play()

[ press "p" to play a note, ctrl-C to break, if that wasn't apparent ] 

sometimes there'll be a delay, sometimes not - but that's just in the luck of the ticks i get a chord 50% of the time i press "p" on my server. 

but that's with 1 block... and i doubt that 1 block is "reliable" or helping the lua be quick, as i'm sure the vanilla block itself isn't as willing to play 2 notes at once as we'd like

so... i did - after adding another note block to the adapter 

[ again, just in a lua prompt here - and using a bit more melodic patterns ]

mbs = {}
for k,v in pairs(components.list()) do if v == "musicblock" then table.insert(mbs,component.proxy(k)) end end
t1 = function() while true do local note = 1 mbs[1].trigger( note ) note = ( note + 4 ) % 24 + 1 coroutine.yield() end end
t2 = function() while true do local note = 4 mbs[2].trigger( note ) note = ( note + 4 ) % 24 + 1 coroutine.yield() end end
c1 = coroutine.create( t1 )
c2 = coroutine.create( t2 )
play = function() while true do  if keyboard.isKeyDown(keyboard.keys.p) then coroutine.resume(c1)  coroutine.resume(c2)  end  event.pull() end
play()

and that, for me, plays simultaneously _most_ of the time... so i think 2 noteblocks helps

and holding down p forever, never crashes - it gets a bit behind, naturally... but it never crashes...  

not sure if that helps you, but it may help you look at the problem another way... 

that is to say, wrap the function which is triggering the note in a coroutine, and call it that way, i'm being lazy in my example and not resuming with parameters to the function... but note that coroutines only resume from the start when they have not yet started... subsequent resumes come in at the point the yield yielded... 
my example is while true do end infinite looping, just to make it fun  
 

sorry no more help, i'd have to look more into the computer event stacking internals to figure out more... 


 

If you've never done this before, you'll love it... i hope

Back in the 80s, at school, we had the wonderful Acorn [who went on to become ARM] "BBC" Machines... the BBC Model A and B...

later superseded by the BBC Master series machines [of which I have two here in my flat, whoo get me and my retro stuff ] 

amazing machines for their time, a gazillion and one external output ports for connecting analogue devices and parallel processors n stuff.

anyway, one of the wonderful things about the BBC Basic was the often missed VDU command, which could be used in certain graphical modes to swap one palette colour for another... i remember sitting in a school induction day for next years pupils, making spheres rotate and stuff, just by doing palette swapping, whilst the visiting parents went "ooooh, look jimmy, you could do this..." 
 

So, ingie? i hear you ask...

well, the same command exists, in effect, within the hologram api on OC... hologram.setPaletteColour*cough ok*Color( paletteindex, hexcolourvalue )

what you might not realise that this enables is simple animation techniques which don't require re-drawing the hologram.

hows that then?

quite simple...

• we have 3 available colours, not counting 0/ black, which we can't change the palette of.
• we draw each of our "frames" in one of those three hologram colours 1,2 and 3
• we then cycle through each colour, changing all but the current one's palette entry to 0x000000, and the current one to whatever we want the animation colour to be...

an example would be nice wouldn't it, ingie... yes, yes it would...

here's a short piece to give you an idea of what's capable with this... it draws a series of sine waves, and then cycles the colours to create a moving "wave" across the sine graph. 

i'll spoiler it, rather than attach it, as it's small, and an attachment means you have to download and open something
i hope it makes sense, if not... feel free to ask.

peace and stuff, ingie. 

--[[holo-wave.lua]]--

local keyboard = require("keyboard")
local component = require("component")
local hologram = component.hologram

hologram.clear()

-- because tau is better than Pi
local tau = math.pi * 2

-- magic numbers
local scale = 10 -- the size of the hologram
local offset = 20 -- the hologram offset from zero which is the zero axis of the sine wave

-- our colours
local dark = 0 -- palette value for "off"
local dim = 0x661133 -- palette value for "nearly off" - change this to 0 for a less subtle animation
local light = 0xff0000 -- palette value for "on"


-- draw our sine waves
-- no need to do it 3 times, but this is an offset to the sin function/voxel position, which makes the image "thicker"
for n = 1,3 do 

  os.sleep(0.01)

    for x = 1,48 do
      for y = 1,48 do

        -- you do the math[s] - the principle is simple sin(x) varies from 0 to 1, 
        -- but we want to scale that up, hence the scale
        local z = math.sin( ( y - x + n) / tau ) * scale + offset 

        -- this might look tricky, but tis just getting the next colour in a sequence of 
        -- 1,2,3,1,2,3,1,2,3... etc... in a way which matches the angle of the wave
        -- play with the formula [leaving the %3 + 1 bit] to get funkier ripples
        local col = (( y - x + n) % 3) + 1 

        hologram.set( x, z, y, col)

        if keyboard.isKeyDown(keyboard.keys.q) then -- quicktime event "press q to die"  
          break
        end

      end
    end
end

-- do the animation, i have set this to just 100 for a demo... 
-- loop if forever if you want, but beware, there is no yielding for the purposes of speed/smoothness
for n = 1, 100 do

-- the % [modulo] bits here are just to get a sequence as 1,2,3 : 2,3,1 : 3,1,2 : 1,2,3 etc.. 
-- for each of the 3 colours [including dark/off]
  hologram.setPaletteColor(((n-2) % 3) + 1,dark)
  hologram.setPaletteColor(((n-1) % 3) + 1,dim)
  hologram.setPaletteColor((n % 3) + 1,light)

end 

i must try this out...

i was wanting to do exactly this for automatically sensing a player with a motion sensor/ct radar and displaying a hologram projection of the player's skin by wrapping the png data around a hologram model...

i'll report back on how that works out for me

i've certainly done this myself with CC, it has many uses... [ moreso with non persistence in CC ] - i had my webserver running a db api on a mysql database for recording various stats of what my machines were up to.

this wasn't "cheating" as you describe, as it was stuff which was outside the "4th wall" to an extent - a bit like how EVE Online gives you full API access to your user data within the game, for making website stat systems outside the game. 

one of the things i have used it for is that I have a node.js app running on one of my raspberryPis at home, and the http call was able to change the colour of an LED system i'd setup on the Pi, changing a tri-colour LED to show the state of various processes within the game...

e.g. one could have an adapter measuring the contents of a chest inventory, and calling the node.js app to set the LED to a colour dependent upon an item count of a specific item in the chest even when you're not logged in

i encourage you to try this at home if you have a raspberry Pi or similar - it's ace