I have a question which might seem stupid 
Now I use:
puts "rate:"
puts rate
how to reduce it to something like
puts "rate: " & rate
What is the way to combine more than 1 argument into a puts on the same line in log? Is it possible?
Hi there
You can do something like this. (I extended to 4 arguments)
rate =1
puts "rate is: ",rate," bpm is ",current_bpm
This gives => "rate is: " 1 " bpm is " 60.0
Cheap and cheerful but nor formatted very nicely
If you want it formatted more nicely you could do:
rate =1
puts "rate is: "+rate.to_s+" bpm is "+current_bpm.to_s
which uses the Ruby .to_s (to string method) to convert each item to a string and they aer then concatenated using the + operator.
This gives => “rate is: 1 bpm is 60.0” on the screen
1 Like
Another option is:
rate = 1
puts "Rate is: #{rate}, BPM is: #{current_bpm}"
1 Like
Thanks for the quick answer!
I like a clean output, but is it worth it? Is the .to_s method less efficient to use, does it cost extra cpu-time?
Running on RPi
I’ve not noticed it causing problems. I use it and similar type conversions quite frequently in programs for Sonic Pi eg to_f to convert to a floating point number.
Okay.
Thanks for the answers. I didn’t find it in the help section. Maybe it can be added that there are at least 3 different ways to combine arguments on 1 puts line.
I’m working on controlling 10 tracks, with each a different editable sample and a different editable sequence, with only a Lpd8.
To be able to control both the patterns and the shape of the samples (attack, release, rate, amp, etc.) of each sample seperately, i’m working with some kind of menu through the log. So each time a knob is turned or a pad pressed, there is puts output. A puts once in a while probably isn’t a big cpu-load, but I guess 8 puts lines at once each time a knob or pad is used, causes quite a lot of latency.
For example pressing pad1 will “select” next sample, for which I can use knobs to adjust rate, attack, release, … Pressing pad1 again selects the next, etc.
This way the 8 knobs times 10 tracks means I can control 80 “things” with only 8 knobs.
Using a second pad means it can become 160 controllable properties.
Anyhow, controlling as many things as possible with the few buttons the Lpd8 has is a great programming challenge for me! I think it’s a good way to learn how to utilise limited physical inputs for maximal possibilities! And also a good way to learn how “decent” coding can be more efficient. Similar to putting effects outside loops, these kinds of things.
Will post code of this experiment later on 
Wow that sounds quite a project. Now I understand why you might be worried about cpu loading using exrtra conversions like .to_s if you `re using so many. Still hopefully it won’t impinge.
I am always amazed that with Sonic Pi you have the flexibility to even attempt so many diverse projects. It is so flexible in the ways that it can work and interface with all the kit that is out there.
What is most amazing to me is how easy it is to use the midi controls in Sonic Pi. Everyone developing it really did a great job! Thank you. I find it is easier to use midi (assign at will to whatever, however way you like) in Sonic Pi than it is in “user friendly” GUI environments I tried like LMMS or Hydrogen 
. Sonic Pi is quite versatile this way.
I even figured it might be a good funding-idea to sell raspberry pi combined with a basic (open source?) midi controller with just a few knobs and sonic pi pre-installed with a few example programs. Because of the midi compatibility anyone could get started for less than 80 €, while most midi equipment is quite expensive and less versatile.
Looking forward to trying many many more fun projects with it, for example also with things like TouchOsc you have suggested in other threads, or in combination with GPIO pins. But first things first 
Any efficiency negligible on the Ruby side are negligible - even on a Raspberry Pi. The big CPU costs are the audio synthesis and the GUI display of the logs. I have noticed that it can be expensive to print to the GUI log on low-powered machines, so printing less rather than avoiding .to_s might help. However, as a principle, the Ruby code typically runs at ‘human time’ so efficiency is rarely an issue.
1 Like