StudioSound 2.00

The new icons are needed for the new “drum track” feature

It’s taken me a while to get to this, but I might have some spare time coming up, so will try to take a look.

I think we should use 256 colours, default palette.

The current set of sprites looks like it has a mix of palettes/colour depths. It would be good to standardise these to 256-colour versions. My preference is generally for optimised palette, ‘new’ format 256-colour sprites, since I think the difference in quality is often detectable. However, if you have strong feelings about using the default palette, let me know.

There’s also the issue of providing low-res and high-res (Sprites11) versions of the file, but perhaps that’s a discussion for once the main set are done.

Chris – I’ll gladly leave those kind of decisions to you.

I think we should use 256 colours, default palette.

Surely anyone using a 32 bit machine would be using upwards from that? (pi default is 16m isn’t it?), if anything (to reduce size) an optimised palette should be used, with maybe an IF switch in the obey to support older hardware? I have always thought that the 22 11 should have been extended so you can provide a filename switch for colour depth as well…

Depending on the icon / images being used default palette can look awful, even in simplistic icons.

Surely anyone using a 32 bit machine would be using upwards from that?

For a standard size icon (34 × 34) I can’t really imagine many occasions when you’d want to use more than 256 colours. I agree that the fixed palette can look a bit poor sometimes, but adopting an optimised palette is fine – bitmaps exported as icons from ArtWorks frequently use less than 256.

There may be Style Guide rules on this (must buy that book!), but for an app’s icons I tend to create a baseline Sprites file in Mode 15, which ensures compatibility with absolutely everything and is very small, and Sprites22 and Sprites11 files that use optimised palettes. These are also pretty small, will work on anything from a RiscPC upwards and give good results.

Notice that StudioSound converts most of the sprites to the current mode, whenever the mode changes. This is for reasons of speed.

I am considering dropping that, except for the backgrund sprite, as I am having trouble converting the mask for some of the sprites, f.ex. the round playback speed icon.

StudioSound 2.07 is now available in PackMan.

The envelopes can now have up to 255 points-
There is a new effect, which subtracts the right channel from the left channel. For stereo samples this will remove the instruments in the center, which is often the voice.
There are also a few bug fixes.
The EDL file format has changed a bit.

See the !Help file for details.

Henrik: I (possibly foolishly) switched the ongoing discussion of StudioSound’s icon design to the Code Review forum, since it wasn’t strictly an Announcement – have a look in case you’ve missed it. If you don’t generally visit the other forums, though, perhaps best to keep the discussion here?

StudioSound 2.09 (the christmas edition) is now available in PackMan.

The most important changes: a few bug fixes, new icons by Chris Wraight, and a new type of tracks: Loop tracks.

Loop tracks are intended for drum loops etc. Any track can be converted to a loop track, by selecting the type from the Track > Type menu.
Segments on loop tracks may be extended to be as long as desired. If a 2 second sample file is extended to 5 minutes, then the file will be played 150 times. This is obviously much easier to deal with than having to create 150 segments.
Loop tracks have a few limitations, and there are aspects of copying/pasting that I haven’t yet figured out how to handle.

Nota: on Pi3, StudioSound is OK, but ProSound does not load.
Internal error: undefined instruction at &206EB950 17722

I installed StudioSound and the StudioLib package from !PackMan.
But the samples are not shown in StudioSound’s “Library” window.
What do I have to to do to access the samples?

Have you take a look to the Wiki ? Here you can find also a link to a scan of my old manual as pdf.

As I remember (my Library exists) you have to open the lib with Adjust (right) click to the iconbar icon. Then copy the content of the downnloaded StudioLib folder to the lib window you open with Adjust.
Go to the Lib window and save the content as default.

There‘s a serious problem with the 32-bit version
of StudioSound.

If you click on the Fade icon and insert a couple
of control points on a track with the mouse, so
that you can do a fade down to the end of a track,
StudioSound gives the message

StudioSound may have gone wrong

then

NULL.POINTER.DEREFERENCE at line 29698.

Although it will let you save the resulting WAVE
file, when you play it with PlayIt, the sound
becomes corrupted, as soon as it hits the point
where the first control point was.

The !RunImage is in BASIC, and line 29698 is in

29674 : REM Shorties
29682 :
29690 : DEFPROCCall(code%,A%,B%,C%,D%,E%,F%)
29698 : CALL
29706 : ENDPROC

if anybody wants to take a look at it.

This didn‘t use to happen on the 26-bit version I
used for years on my RiscPC.

I‘ve tried getting a RiscPC version working, using
Aemulor, but it needs the DotMatrix font, and when
you install it in !Fonts in the !Boot directory,
it doesn‘t actually load the font, when it boots up.

I‘d really like to get the Fade effect working,
because – if I can – I‘m planning to write something
for Drag n Drop about using StudioSound.

Jon Robinson, Leeds

Hi Jon
I have version 2.09 (19-dec 2016) available here:

I can’t find line > 2258 in the !RunImage, but I found DEFPROCcall:

DEFPROCCall(code%,A%,B%,C%,D%,E%,F%)
CALL
ENDPROC
Indeed, something is missing in your procedure…
Your test works fine with this version.
I also use !Prosound to listen to musical passages on a loop to transcribe them into Raphsody.
Nice(s) softwares

There’s a serious problem with the 32-bit version of StudioSound.

You do not say which version, or what you are running on, but I have just downloaded v1.09 as suggested by JMB above.
The line numbers are correct, but the CALL was missing the parameters, shown below.

29690 : DEFPROCCall(code%,A%,B%,C%,D%,E%,F%)
29698 : CALL(Code%+code%)
29706 : ENDPROC

I ran it on my Titanium with RO5.31, and I tried to replicate your problem, but failed – but I have never used ProSound. Detailed instructions to reproduce may help.

It seems that Code% is where the file Code is loaded, which is 69KB of assembled code.
code% is an offset into that code, probably into a large jump table at the start with 320 different entry points (code%=0 to &504)
A% to F% are variables to put into registers r0 tor5 respectively.
Somewhere in that code it has tried to to use a value of zero as a pointer to another value … which is invalid … and it has returned to BASIC, which reports the error with the BASIC line number of the CALL (which is all it can do).

Without the values of all the parameters to the PROCcall that caused the problem, plus preferably the source of the assembled code, diagnosis will be difficult. If you are running the ZeroPain module, that may have logged an error which may have some clues. The *ShowRegs command, the *Where commmand, and then a *Memoryi around the failing code, may also help.

The variable values could be found by running Reporter, and adding after the DEF PROCcall line

*Report \t \? ~Code% ~code% ~A% ~B% ~C% ~D% ~E% ~F%